Re: Another mapfile question.
IFS= aa=() while read line do aa+=($line) done fn You should really put that IFS= on your 'read', so as not to break the default wordsplitting for the rest of your script: while IFS= read -r line vs. IFS=$'\n' aa=($( fn)) Don't leave expansions unquoted! you're still permitting pathname expansion here. IFS=$'\n' read -rd '' -a aa (fn) vs. mapfile -t aa fn When compared to the above read, this will also read empty lines. The read operation will merge multiple newlines into a single delimiter (as it does for all types of whitespace in IFS). The while read works fine but is verbose. The mapfile is a bit more concise. The read -a is fine and concise so long as you can live with the lack of empty lines. I doubt mapfile is much use to you that while read doesn't already give you. smime.p7s Description: S/MIME cryptographic signature
Re: Another mapfile question.
On 8/5/2011 9:08 AM, Maarten Billemont wrote:
IFS=
aa=()
while read line
do
aa+=($line)
done fn
You should really put that IFS= on your 'read', so as not to break the default
wordsplitting for the rest of your script:
For purposes of giving concise examples on this email list, I wrote it as
above. In practice, something like the above construct that modifies IFS would
be responsible for restoring IFS. e.g.,
old_IFS=$IFS
# do stuff
IFS=$old_IFS
More often, the code would be placed in a subroutine where IFS is declared as
a local variable. Within that routine, if IFS needs to be restored, then
old_IFS would also be locally declared. If IFS did not need to be restored
(within the routine) then old_IFS might not even need to be declared.
One trick that bit me a while back, is that the order of declaring IFS and
old_IFS is important. It has to be done in this order:
foo()
{
typeset -r old_IFS=$IFS # Must come first
typeset IFS
stuff...
}
This is because the initial value to old_IFS is referring to the outer scoped
IFS. It is nice though that the locally declared IFS gets an initial value
from the outer scope :-)
while IFS= read -r line
vs.
IFS=$'\n'
aa=($( fn))
Don't leave expansions unquoted! you're still permitting pathname expansion
here.
IFS=$'\n' read -rd '' -a aa (fn)
vs.
mapfile -t aa fn
When compared to the above read, this will also read empty lines. The read
operation will merge multiple newlines into a single delimiter (as it does for
all types of whitespace in IFS).
The while read works fine but is verbose. The mapfile is a bit more concise.
The read -a is fine and concise so long as you can live with the lack of empty
lines. I doubt mapfile is much use to you that while read doesn't already give
you.
--
Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net
bug: return doesn't accept negative numbers
I guess I don't use negative return codes that often in shell, but I use them as exit codes reasonably often. 'return' barfs on return -1... Since return is defined to take no options, and ONLY an integer, as the return code, it shouldn't be hard to fix. Seem to fail on any negative number, but 'exit status' is defined as a short int -- not an unsigned value (i.e. -1 would return 255).
Re: bug: return doesn't accept negative numbers
On 08/05/2011 05:41 PM, Linda Walsh wrote:
I guess I don't use negative return codes that often in shell, but
I use them as exit codes reasonably often.
'return' barfs on return -1...
Since return is defined to take no options, and ONLY an integer,
as the return code, it shouldn't be hard to fix.
According to POSIX, it's not broken in the first place. Portable shell
is requires to pass an unsigned decimal integer, no greater than 255,
for defined behavior.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#return
Seem to fail on any negative number, but 'exit status' is defined
as a short int -- not an unsigned value (i.e. -1 would return 255).
In bash, 'return -- -1' sets $? to 255 (note the --). But since that is
already an extension (POSIX does not require 'return' to support -- any
more than it is required to support an argument of -1), I agree with
your argument that bash would be more useful if, as an extension to
POSIX, it would handle 'return -1' - in fact, that would match ksh
behavior. Conversely, since portable code already can't use it, it's no
skin off my back if nothing changes here.
$ bash -c 'f() { return -- -1; }; f; echo $?'
255
$ bash -c 'f() { return -1; }; f; echo $?'
bash: line 0: return: -1: invalid option
return: usage: return [n]
2
$ dash -c 'f() { return -- -1; }; f; echo $?'
return: 1: Illegal number: --
$ dash -c 'f() { return -1; }; f; echo $?'
return: 1: Illegal number: -1
$ ksh -c 'f() { return -- -1; }; f; echo $?'
255
$ ksh -c 'f() { return -1; }; f; echo $?'
255
$
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
Re: bug: return doesn't accept negative numbers
Eric Blake wrote: Linda Walsh wrote: I guess I don't use negative return codes that often in shell, but I use them as exit codes reasonably often. For all of the reasons Eric mentioned you won't ever actually be able to see a negative result of an exit code however. 'return' barfs on return -1... Since return is defined to take no options, and ONLY an integer, as the return code, it shouldn't be hard to fix. According to POSIX, it's not broken in the first place. Portable shell is requires to pass an unsigned decimal integer, no greater than 255, for defined behavior. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#return The reason for that is for compatibility. Originally the exit status was returned in a 16 bit integer with the lower 8 bit byte holding the exit code and the upper 8 bit byte holding the status. The wait.h macros WTERMSIG et al were used to extract that information. (I don't know if all of that is still true but that is the way it used to be.) And so in the C programming man page for exit(3) it says: man 3 exit The exit() function causes normal process termination and the value of status 0377 is returned to the parent (see wait(2)). Note the status 0377 part. That is an octal 0377 or 255 decimal or 0xFF hexadecimal or just the lower 8 bits. Trying to return a value that won't fit into 8 bits just isn't possible. The traditional man pages always described the size as an 8 bit value and specified the range as 0 through 255 implying that it was an unsigned value. Historical documentation for exit(3) http://www.freebsd.org/cgi/man.cgi?query=exitapropos=0sektion=3manpath=2.9.1+BSDformat=html Now you might argue that -1 is always going to be all ones in two's complement. Sure. But traditionally it has always been unsigned. Bob
Re: bug: return doesn't accept negative numbers
return (and exit) returns an exit code between 0 and 255. Zero means true and anything else means false If you want a function to return a value, use printf or echo. On Fri, Aug 5, 2011 at 6:41 PM, Linda Walsh b...@tlinx.org wrote: I guess I don't use negative return codes that often in shell, but I use them as exit codes reasonably often. 'return' barfs on return -1... Since return is defined to take no options, and ONLY an integer, as the return code, it shouldn't be hard to fix. Seem to fail on any negative number, but 'exit status' is defined as a short int -- not an unsigned value (i.e. -1 would return 255). -- Visit serverfault.com to get your system administration questions answered.
Re: bug: return doesn't accept negative numbers
Linda Walsh wrote: Seem to fail on any negative number, but 'exit status' is defined as a short int -- not an unsigned value (i.e. -1 would return 255). Bob Proulx wrote: Eric Blake wrote: Linda Walsh wrote: I guess I don't use negative return codes that often in shell, but I use them as exit codes reasonably often. For all of the reasons Eric mentioned you won't ever actually be able to see a negative result of an exit code however. I never said anything about 'seeing' -1, in fact, I stated just that -1 would return 255. return says 'if no args are given' will return exit status of the last command executed', so (exit -1);echo $? = 255 (exit -2);echo $? = 254 ... Which is also the way it works in 'C', and perl. AFAIK, from a compiler perspective, if the value is able to be represented as a signed-8-bit quantity, conversion is done (i.e. short int becomes signed char). Seems that return should handle the same exit values as 'exit'. Isn't return supposed to be the 'exit value' of a function?
