My bash shell suddenly has "X-ray vision"

My bash shell suddenly has "X-ray vision"

[SJ Wright]

Or is it just the difference in encodings?

In scripts and config/convenience files like .bashrc or .bash_aliases, 
it can see *through* "crunches" (#), which are supposed to make a line 
of text invisible to a shell <or am I wrong on that?>

Could it be because I added a LANG variable and have been turning out 
not-quite-UTF-8 stuff from my one or two text editors? The only guess I 
can make with my limited knowledge is that, once UTF8 is set or enabled, 
ISO-8859-1 "crunches," for all practical purposes, are meaningless to 
the shell.  or am I wrong on that as well?

A little help, please. This isn't making a whole lot of sense. What good 
are rules for comments if, when a new text encoding or environment 
variable is applied/undertaken/invoked, they become null and void? 
(Might as well go back to REM: from CLI BASIC.)

Steve W


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: My bash shell suddenly has "X-ray vision"

[Larry Hall (Cygwin)]

On 9/25/2010 9:27 PM, SJ Wright wrote:
> Or is it just the difference in encodings?
>
> In scripts and config/convenience files like .bashrc or .bash_aliases, it can
>  see *through* "crunches" (#), which are supposed to make a line of text
> invisible to a shell <or am I wrong on that?>
>
> Could it be because I added a LANG variable and have been turning out
> not-quite-UTF-8 stuff from my one or two text editors? The only guess I can
> make with my limited knowledge is that, once UTF8 is set or enabled,
> ISO-8859-1 "crunches," for all practical purposes, are meaningless to the
> shell. or am I wrong on that as well?
>
> A little help, please. This isn't making a whole lot of sense. What good are
>  rules for comments if, when a new text encoding or environment variable is
> applied/undertaken/invoked, they become null and void? (Might as well go back
> to REM: from CLI BASIC.)

I suggest you run 'd2u' on the files and see if that helps.  If it does, you
know that some editing you did on those files introduced DOS/Windows line
endings.

-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: My bash shell suddenly has "X-ray vision"

[SJ Wright]

[-- Attachment #1: Type: text/plain, Size: 2201 bytes --]

Larry Hall (Cygwin) wrote:
> On 9/25/2010 9:27 PM, SJ Wright wrote:
>> Or is it just the difference in encodings?
>>
>> In scripts and config/convenience files like .bashrc or 
>> .bash_aliases, it can
>>  see *through* "crunches" (#), which are supposed to make a line of text
>> invisible to a shell <or am I wrong on that?>
>>
>> Could it be because I added a LANG variable and have been turning out
>> not-quite-UTF-8 stuff from my one or two text editors? The only guess 
>> I can
>> make with my limited knowledge is that, once UTF8 is set or enabled,
>> ISO-8859-1 "crunches," for all practical purposes, are meaningless to 
>> the
>> shell. or am I wrong on that as well?
>>
>> A little help, please. This isn't making a whole lot of sense. What 
>> good are
>>  rules for comments if, when a new text encoding or environment 
>> variable is
>> applied/undertaken/invoked, they become null and void? (Might as well 
>> go back
>> to REM: from CLI BASIC.)
>
> I suggest you run 'd2u' on the files and see if that helps.  If it 
> does, you
> know that some editing you did on those files introduced DOS/Windows line
> endings.
>
I did something slightly different, inspired by your suggestion. I wrote 
up a quickie script to get the magic number returns from 'find' on all 
my dotfiles. This after running several different combinations of 'cat' 
with options. Re ALL the files in question:  there were *NO* ^M markers 
at the end of any line.  I regard running dos2unix a waste of time if I 
don't see some indication of non-Unix encoding/formatting on a file or 
files ahead of time. And I may not know much but I know what to look 
for. Or maybe you'd prefer to take up the subject of what saves which 
correctly with the developers of Emerald Editor, which I use both in 
Windows and Ubu Linux to compose scripts and edit dotfiles regularly 
when I'm not in the mood for the mouseless approach vi and nano restrict 
one to.

A solution that's not a solution isn't even worth considering (was that 
Einstein or Schrodinger? Maybe it was Dr Moore.)

steve w

Attached is the output to text of that script (which returned as 
"*magic_returns_dotfiles.txt: ASCII text*" one-half second ago).


[-- Attachment #2: magic_returns_dotfiles.txt --]
[-- Type: text/plain, Size: 624 bytes --]

~/.Xauthority: empty
~/.Xdefaults: ASCII text
~/.Xresources: Little-endian UTF-16 Unicode text, with CRLF line terminators
~/.bash_aliases: ASCII English text
~/.bash_history: ASCII English text
~/.bash_profile: ASCII English text
~/.bashrc: ASCII English text
~/.blackboxrc: ASCII text
~/.curlrc: ASCII text
~/.gtk-bookmarks: ASCII text
~/.imrc: ASCII text
~/.inputrc: ASCII English text
~/.jwmrc: XML  document text
~/.minttyrc: ASCII text
~/.profile: ASCII English text
~/.wmcliphistrc: empty
~/.xinitrc: POSIX shell script text executable
~/.xserverrc: POSIX shell script text executable
~/.xsession: ASCII English text

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: My bash shell suddenly has "X-ray vision"

[Andy Koppe]

On 27 September 2010 04:27, SJ Wright wrote:
>>> Or is it just the difference in encodings?
>>>
>>> In scripts and config/convenience files like .bashrc or .bash_aliases, it
>>> can
>>>  see *through* "crunches" (#), which are supposed to make a line of text
>>> invisible to a shell <or am I wrong on that?>
>>>
>>> Could it be because I added a LANG variable and have been turning out
>>> not-quite-UTF-8 stuff from my one or two text editors? The only guess I
>>> can
>>> make with my limited knowledge is that, once UTF8 is set or enabled,
>>> ISO-8859-1 "crunches," for all practical purposes, are meaningless to the
>>> shell.

To answer that part: no, UTF-8 vs ISO-8859-1 makes no difference to
that symbol, because it's part of the ASCII range, which is shared
between all of the character encodings supported by Cygwin.

> the mouseless approach vi and nano restrict one to.

They do you have some mouse support actually. Enable with ':set
mouse=a' in vim, and with Alt+m in nano.

> ~/.Xresources: Little-endian UTF-16 Unicode text, with CRLF line terminators

That one won't work, because UTF-16 is not ASCII-compatible.

Andy

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple