Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #11284

Re: BUG?: (or what's going on?) test for NL == NL fails (bash-4.3.39(3)-release)

From Linda Walsh <bash@tlinx.org>
Newsgroups gnu.bash.bug
Subject Re: BUG?: (or what's going on?) test for NL == NL fails (bash-4.3.39(3)-release)
Date 2015-08-02 13:30 -0700
Message-ID <mailman.7765.1438547424.904.bug-bash@gnu.org> (permalink)
References <55BE6FB8.4080200@tlinx.org>

Show all headers | View raw


also noticed this similar strange behavior:

used 'ord'** for this test (trying to compare decimal val of chars)

isatty () { test -c /proc/self/fd/1 ; }
ord () { local nl=""; isatty && nl="\n"; printf "%d$nl" "'$1" ; } 

> ord "$(printf "\n")"
0
ord "$(printf "\t")"
9
> ord "$(printf " ")"
32
> ord "$(printf "\r")"
13
-- but this DOES work:
> ord $'\n'
10
----
Traditional separators and CR work, -- just "\n".
Am just looking for an efficient way to test for 0x0a
as last char in a var, ... after another 20 minutes of
trying things at random, found this:

  > printf "%d\n" "'${a:0-1:1}'"
  10

Oddly, the final single quote in the string seems unnecessary.
But that (or into a var: printf -v var) both work...but I
feel a bit contorted trying so many odd ways to get something
that I thought would be simple, to work.

Still... why so many problems with \n?
I tried unsetting IFS ---- even setting both "eol" chars,
explicitly (I wondered if both eol chars were 'undef'
w/stty:

> stty
speed 38400 baud; line = 0;
kill = ^X; eol = #; eol2 = #; susp = ^Y;   ## yes, I set both eol chars to '#'
only to find it didn't change anything (LF was still end of line).
:-(



Back to gnu.bash.bug | Previous | Next | Find similar


Thread

Re: BUG?: (or what's going on?) test for NL == NL fails (bash-4.3.39(3)-release) Linda Walsh <bash@tlinx.org> - 2015-08-02 13:30 -0700

csiph-web