Re: builtin "read -d" behaves differently after "set -e#
On Wed, Feb 06, 2013 at 12:39:45AM +0100, Tiwo W. wrote:
> When using this in a script of mine, I noticed that this fails
> when errexit is set ("set -e").
Most things do. set -e is crap. You should consider not using it.
> * why does it work with "set +e" ?
Because set +e disables the crap.
> * what is the recommended way to disable splitting with "read"?
What splitting? You only gave a single variable. There is no field
splitting when you only give one variable.
> set -e
> read -d '' var2 this
>fails
> EOF
> echo "$var2"
Are you actually asking how to force read to slurp in an entire file
including newlines, all at once? Is that what you meant by "splitting"?
Well, you already found your answer -- stop using set -e. By the way,
you may also want to set IFS to an empty string to disable the trimming
of leading and trailing whitespace, and use the -r option to suppress
special handling of backslashes. Thus:
IFS= read -rd '' var2 < blah
> EOF
imadev:~$ echo $?
1
read returns 1 because it reached the end of file for standard input.
>From the manual: "The return code is zero, unless end-of-file is
encountered, read times out (in which case the return code is greater than
128), or an invalid file descriptor is supplied as the argument to -u."
So, if you're reading all the way to EOF (on purpose) then you should
ignore the exit status. set -e doesn't permit you to ignore the exit
status on commands where the exit status indicates a nonfatal condition
(such as read -d '' or let i=0). This is why set -e is crap.
Also see http://mywiki.wooledge.org/BashFAQ/105
When cd'd into a symlinked directory, directory completion can sometimes erroneously parse ../
Do: mkdir cd mkdir -p dir1/dir2 ln -s dir1/dir2 ouch touch idontexist ls # ^ to see dir & files & prove they really exist :P cd ouch ls ../ido ... :P I can see why this exists... this is a complex one to solve. *leaves it to you to figure it out* xD -i336
Re: When cd'd into a symlinked directory, directory completion can sometimes erroneously parse ../
On 2/5/13 10:23 PM, i336 wrote: > Do: > > mkdir > cd > mkdir -p dir1/dir2 > ln -s dir1/dir2 ouch > touch idontexist > ls # ^ to see dir & files & prove they really exist :P > cd ouch > ls ../ido > > ... Filename completion uses whatever file system view -- logical or physical -- that you have selected for bash. The default is a logical view. `ls', on the other hand, doesn't know anything about that. This is not solvable unless you decide to use a physical view consistently (set -o physical). Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: builtin "read -d" behaves differently after "set -e#
Am 06.02.2013 14:46, schrieb Greg Wooledge:
> On Wed, Feb 06, 2013 at 12:39:45AM +0100, Tiwo W. wrote:
>> When using this in a script of mine, I noticed that this fails
>> when errexit is set ("set -e").
> Most things do. set -e is crap. You should consider not using it.
>
>> * why does it work with "set +e" ?
> Because set +e disables the crap.
>
>> * what is the recommended way to disable splitting with "read"?
> What splitting? You only gave a single variable. There is no field
> splitting when you only give one variable.
>
>> set -e
>> read -d '' var2 <>but
>>this
>>fails
>> EOF
>> echo "$var2"
> Are you actually asking how to force read to slurp in an entire file
> including newlines, all at once? Is that what you meant by "splitting"?
>
> Well, you already found your answer -- stop using set -e. By the way,
> you may also want to set IFS to an empty string to disable the trimming
> of leading and trailing whitespace, and use the -r option to suppress
> special handling of backslashes. Thus:
>
> IFS= read -rd '' var2 <
> In case you're curious why set -e makes it fail:
>
> imadev:~$ IFS= read -rd '' foo < > blah
> > EOF
> imadev:~$ echo $?
> 1
>
> read returns 1 because it reached the end of file for standard input.
> From the manual: "The return code is zero, unless end-of-file is
> encountered, read times out (in which case the return code is greater than
> 128), or an invalid file descriptor is supplied as the argument to -u."
>
> So, if you're reading all the way to EOF (on purpose) then you should
> ignore the exit status. set -e doesn't permit you to ignore the exit
> status on commands where the exit status indicates a nonfatal condition
> (such as read -d '' or let i=0). This is why set -e is crap.
>
> Also see http://mywiki.wooledge.org/BashFAQ/105
>
set -e
IFS= read -rd '' var2 <
Re: builtin "read -d" behaves differently after "set -e#
On Wed, Feb 06, 2013 at 07:12:01PM +0100, John Kearney wrote: > IFS= read -rd '' var2 < > should work. Which is essentially equivalent to doing "set +e" before, and "set -e" again right after. In either case, you're temporarily working around the brokenness of set -e for a single command.
Re: builtin "read -d" behaves differently after "set -e#
On Tue, Feb 5, 2013 at 6:39 PM, Tiwo W. wrote: > I have seen "read -d '' var" to read multi-line heredocs into > shell variables. An empty argument to -d seemed to mean "read > up to the end of input". And this is what it does. > > In addition to all of the "don't use set -e" answers you've gotten (which i agree with wholeheartedly), I have this to add: read -rd '' is synonymous to read -d $'\0'. It doesn't actually mean "read until the end of input", but rather "read until a NUL byte is encountered". You see this usage a lot as well when reading NUL-delimited data, say filenames from find. For example: while IFS= read -rd '' file; do some_command "$file" done < <(find . -type f -print0) So what's actually happening with your here document usage case is that read is looking for a NUL byte, but never finds one, so it stops reading when EOF is encountered. As Greg mentioned, this then casuse read to exit > 0. This is a perfectly acceptable usage, but now you know why that happens. And to reiterate, STOP USING set -e!
Re: builtin "read -d" behaves differently after "set -e#
On Wednesday, February 06, 2013 01:44:04 PM DJ Mills wrote: > On Tue, Feb 5, 2013 at 6:39 PM, Tiwo W. wrote: > > > I have seen "read -d '' var" to read multi-line heredocs into > > shell variables. An empty argument to -d seemed to mean "read > > up to the end of input". And this is what it does. > > > > > In addition to all of the "don't use set -e" answers you've gotten (which i > agree with wholeheartedly), I have this to add: > > read -rd '' is synonymous to read -d $'\0'. It doesn't actually mean "read > until the end of input", but rather "read until a NUL byte is encountered". > You see this usage a lot as well when reading NUL-delimited data, say > filenames from find. For example: > > while IFS= read -rd '' file; do > some_command "$file" > done < <(find . -type f -print0) > > So what's actually happening with your here document usage case is that > read is looking for a NUL byte, but never finds one, so it stops reading > when EOF is encountered. As Greg mentioned, this then casuse read to exit > > 0. This is a perfectly acceptable usage, but now you know why that happens. > > And to reiterate, STOP USING set -e! +1 to all of that. Note $'\0' was used here for illustration and doesn't actually expand to a nul byte. To be completely clear, the command: `read -rd '' x' is literally receiving the same arguments as the $'\0' case -- it's not only that `read' is treating them the same. Also, if it means anything, sadly ksh93 didn't perform that termination until one of the most recent alphas. I take it that this is sort of an extra special feature that most shells with -d happen to share, and not merely a necessary consequence of -d with an empty arg. Hopefully someday `mapfile' will inherit an analogous feature. -- Dan Douglas
Re: When cd'd into a symlinked directory, directory completion can sometimes erroneously parse ../
Chet Ramey wrote: > i336 wrote: > > mkdir -p dir1/dir2 > > ln -s dir1/dir2 ouch > > touch idontexist > > ls # ^ to see dir & files & prove they really exist :P > > cd ouch > > ls ../ido > > ... > > Filename completion uses whatever file system view -- logical or physical > -- that you have selected for bash. The default is a logical view. `ls', > on the other hand, doesn't know anything about that. This is not solvable > unless you decide to use a physical view consistently (set -o physical). I always use 'set -o physical' everywhere to have consistent behavior. The evil truth is better than a good lie. Bob
