Re: unexpected behavior of 'read' builtin
Juliano F. Ravasi wrote: > The second one is that it chops leading and trailing whitespace > when you provide one variable for assignment, and not when you > use the default $REPLY. > > I don't know if these are intended behavior, but it doesn't seem > to be documented, leading to a surprise when you expect > something and get some other thing instead. > > Repeat-By: > > [...] > > About trailing and leading whitespace: > > ~$ read <<< ' a b '; declare -p REPLY > declare -- REPLY=" a b " > > ~$ read VAR <<< ' a b '; declare -p VAR > declare -- VAR="a b" > > Note how whitespace is removed when using $VAR, but not when > using $REPLY. IMO the key for that behaviour is already in the docs: "...with leftover words and their intervening separators assigned to the last name." (read with variable name supplied) and here: "If no names are supplied, the line read is assigned to the variable REPLY." The difference I see is: - with variable name supplied, it's split into words and leftover words are stored with their intervening separators into the last variable given. Since there is only one variable, the effect is what you see. - without any variable name supplied (default: REPLY), the line (!) is stored. J.
Re: unexpected behavior of 'read' builtin
On Saturday 24 May 2008 02:44, Juliano F. Ravasi wrote: > Description: > > I got bitten by two unexpected (and undocumented) behaviors of > the 'read' builtin. > > The first one is that it doesn't seem to handle word separators > equally, making distinction when spaces and non-space > separators are used to separate words. The man page introduces the concept of "IFS whitespace", which seems to include space and tab characters. "If IFS has a value other than the default, then sequences of the whitespace characters space and tab are ignored at the beginning and end of the word, as long as the whitespace character is in the value of IFS (an IFS whitespace character). Any character in IFS that is not IFS whitespace, along with any adjacent IFS whitespace characters, delimits a field. A sequence of IFS whitespace characters is also treated as a delimiter." So, if I read that correctly (which might not be true of course), when you assign $'\t' (an IFS whitespace character) to IFS, it seems you fall into the case where "a sequence of IFS whitespace characters is also treated as a delimiter". > The second one is that it chops leading and trailing whitespace > when you provide one variable for assignment, and not when you > use the default $REPLY. This /seems/ to be documented. From the man page, section about "read": "If no names are supplied, the line read is assigned to the variable REPLY". So, I guess "the line read" here really means "the whole line", including leading/trailing spaces. On the other hand, when even a single name is supplied, word splitting is performed, so the removal of blanks is expected as the result of that. -- D.
Re: unexpected behavior of 'read' builtin
Juliano F. Ravasi wrote: I got bitten by two unexpected (and undocumented) behaviors of the 'read' builtin. The first one is that it doesn't seem to handle word separators equally, making distinction when spaces and non-space separators are used to separate words. Posix makes the distinction explicit. Read the `Field Splitting' section (2.6.5) in http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_05 The second one is that it chops leading and trailing whitespace when you provide one variable for assignment, and not when you use the default $REPLY. This is the behavior to which the language in the man page that talks about `the line read' being assigned to REPLY refers. Bash behaves as it does when using REPLY to make it easy to read an entire line verbatim without having to temporarily alter $IFS. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Missing .bash_history Entries
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='l$ uname output: Linux jaguar 2.6.24-16-generic #1 SMP Thu Apr 10 12:47:45 UTC 200$ Machine Type: x86_64-pc-linux-gnu Bash Version: 3.2 Patch Level: 33 Release Status: release Description: It is possible to execute commands from the command-line without them appearing in the .bash_history file. This is a slight nuisance as any command that is accidentally preceded with a space will not appear when cycling through commands using the arrow keys. Repeat-By: Precede the command to execute with a single space. Fix: Don't type in a space by accident. ;-)
Re: Missing .bash_history Entries
On Sat, May 24, 2008 at 10:46:40AM -0700, Dave Jarvis wrote: > Description: > It is possible to execute commands from the command-line > without them appearing in the .bash_history file. This is a slight > nuisance as any command that is accidentally preceded with a space > will not appear when cycling through commands using the arrow keys. That is a documented feature. It only ignores lines starting with space if HISTCONTROL is set to a value including "ignorespace" or "ignoreboth". -- Mike Stroyan <[EMAIL PROTECTED]>
