Re: why must non-standard $IFS members be treated so differently ?
On Sunday, July 29, 2012 03:23:29 PM Jason Vas Dias wrote:
echo $(count_args 1 2 3\ 4)
I should also have mentioned that I couldn't reproduce this case. You should
be getting 4 here in your example, not 3. I have the same Bash version. Are
you sure you were echoing `${#v[@]} ' and not `${#@}', and also that you did
not set IFS=: for count_args? If you use exactly the function you sent with
the default IFS then you should get 4 here.
--
Dan Douglas
signature.asc
Description: This is a digitally signed message part.
Re: EXIT traps in interactive shells
On 7/28/12 12:38 PM, Maarten Billemont wrote:
Trapping on EXIT is a really convenient way of cleaning up after yourself
when your script ends.
I agree that the EXIT trap should work on {} asynchronous subshells, and I
will make sure that the next version of bash does this.
However, the two examples you gave don't really differ in that respect. If
you take out the `kill', neither interactive nor non-interactive shells run
the exit trap. The difference is how interactive and non-interactive
shells handle SIGTERM. That's the place I'll have to look.
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: why must non-standard $IFS members be treated so differently ?
On Sun, 29 Jul 2012, Jason Vas Dias wrote:
Good day Chet, list -
I'm concerned about the difference in output of these functions with
the example input
given on the '$' prefixed line below (with 4.2.29(2)-release
(x86_64-unknown-linux-gnu)):
function count_args {v=($@); echo ${#v[@]}; }
Always quote $@. Without quotes, it's the same as $*
function count_args {v=( $@ ); echo ${#v[@]}; }
--
Chris F.A. Johnson, http://cfajohnson.com/
Author:
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Re: why must non-standard $IFS members be treated so differently ?
Thanks Dan -
The plot thickens - Yes, you're right, I had $IFS mistakenly set to ':' in the
shell in which I ran 'count_args' . Without this IFS setting, I get
a count of 4:
$ env -i PATH=/bin:/usr/bin HOME=${HOME} /bin/bash --norc
$ count_args 1 2 3\ 4
4
$ IFS=: count_args 1 2 3\ 4
3
This to me is strange , as I've asked bash not to use ' ' as a
delimiter, when $IFS==: , but it is doing so !
And shouldn't '3\ 4' be a single string in any case, regardless of IFS ?
If word splitting is not doing any escaping, why not - shouldn't it
be doing so?
Escaping works in filenames, so why not in word-splitting ?
Thanks Regards,
Jason
On Sun, Jul 29, 2012 at 4:19 PM, Dan Douglas orm...@gmail.com wrote:
On Sunday, July 29, 2012 03:23:29 PM Jason Vas Dias wrote:
echo $(count_args 1 2 3\ 4)
I should also have mentioned that I couldn't reproduce this case. You should
be getting 4 here in your example, not 3. I have the same Bash version. Are
you sure you were echoing `${#v[@]} ' and not `${#@}', and also that you did
not set IFS=: for count_args? If you use exactly the function you sent with
the default IFS then you should get 4 here.
--
Dan Douglas
RE:
why must non-standard $IFS members be treated so differently ?
Jason Vas Dias
3:23 PM (4 hours ago)
Good day Chet, list -
I'm concerned about the difference in output of these functions with
the example input
given on the '$' prefixed line below (with 4.2.29(2)-release
(x86_64-unknown-linux-gnu)):
function count_args {v=($@); echo ${#v[@]}; }
function count_colons { IFS=':' ;v=($@); echo ${#v[@]}; }
$ echo $(count_args 1 2 3\ 4) $(count_colons 1:2:3\:4)
3 4
It appears to be impossible for an item delimited by 'X' to contain
an escaped 'X' ('\X') if 'X' is not
a standard delimiter (' ', 'TAB') . Quoting doesn't seem to help either:
$ echo $(count_args 1 2 3\ 4) $(count_colons 1:2:3':4')
3 4
To me, this appears to be a bug.
But I bet you're going to tell me it is a feature ?
Please explain.
Thanks Regards,
Jason
BTW, documentation on $IFS does not appear to mention this issue:
Word Splitting
The shell scans the results of parameter expansion, command
substitution, and arithmetic expansion that did not occur within
double quotes for word splitting.
The shell treats each character of IFS as a delimiter, and
splits the results of the other expansions into words on these
characters. If IFS is unset, or its value is exactly
spacetabnewline, the default, then sequences of space,
tab, and newline at the beginning and end of the results of the
previous expansions are ignored, and any sequence of IFS charac-
ters not at the beginning or end serves to delimit words. 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. If the
value of IFS is null, no word splitting occurs.
Re: why must non-standard $IFS members be treated so differently ?
Jason Vas Dias jason.vas.d...@gmail.com writes:
Thanks Dan -
The plot thickens - Yes, you're right, I had $IFS mistakenly set to ':' in
the
shell in which I ran 'count_args' . Without this IFS setting, I get
a count of 4:
$ env -i PATH=/bin:/usr/bin HOME=${HOME} /bin/bash --norc
$ count_args 1 2 3\ 4
4
$ IFS=: count_args 1 2 3\ 4
3
This to me is strange , as I've asked bash not to use ' ' as a
delimiter, when $IFS==: , but it is doing so !
IFS does not change the shell syntax. It only controls field splitting
as applied to the result of expansions. Compare:
$ bash -c 'IFS=:; echo a:b:c'
a:b:c
$ bash -c 'IFS=:; a=a:b:c; echo $a $a'
a:b:c a b c
$ bash -c 'IFS=:; a=a:b:c; b=$a; echo $b $b'
a:b:c a b c
In the last example the assignment b=$a doesn't undergo field
splitting, so the colons are still preserved.
And shouldn't '3\ 4' be a single string in any case, regardless of IFS ?
It is. But if field splitting is applied to it it will be split in two
words when $IFS contains a space.
If word splitting is not doing any escaping, why not - shouldn't it
be doing so?
Escape characters are part of the shell syntax. They are never special
when they result from expansions, unless they are reinterpreted as shell
input through eval.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
Re: why must non-standard $IFS members be treated so differently ?
Thanks Andreas -
I guess your answer mostly explains my issue - except for one thing:
And shouldn't '3\ 4' be a single string in any case, regardless of IFS ?
It is. But if field splitting is applied to it it will be split in two
words when $IFS contains a space.
This was really the point of my question - why, if escaping is permitted and
an escape is shell syntax, does word-splitting not honor escapes, ESPECIALLY
if the character being escaped is a character in $IFS ?
Would it be much work to make word-splitting honor escapes ?
Why is this issue of escaping not being enabled during word-splitting
not documented anywhere ?
Thanks Regards,
Jason
On Sun, Jul 29, 2012 at 9:05 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Jason Vas Dias jason.vas.d...@gmail.com writes:
Thanks Dan -
The plot thickens - Yes, you're right, I had $IFS mistakenly set to ':' in
the
shell in which I ran 'count_args' . Without this IFS setting, I get
a count of 4:
$ env -i PATH=/bin:/usr/bin HOME=${HOME} /bin/bash --norc
$ count_args 1 2 3\ 4
4
$ IFS=: count_args 1 2 3\ 4
3
This to me is strange , as I've asked bash not to use ' ' as a
delimiter, when $IFS==: , but it is doing so !
IFS does not change the shell syntax. It only controls field splitting
as applied to the result of expansions. Compare:
$ bash -c 'IFS=:; echo a:b:c'
a:b:c
$ bash -c 'IFS=:; a=a:b:c; echo $a $a'
a:b:c a b c
$ bash -c 'IFS=:; a=a:b:c; b=$a; echo $b $b'
a:b:c a b c
In the last example the assignment b=$a doesn't undergo field
splitting, so the colons are still preserved.
And shouldn't '3\ 4' be a single string in any case, regardless of IFS ?
It is. But if field splitting is applied to it it will be split in two
words when $IFS contains a space.
If word splitting is not doing any escaping, why not - shouldn't it
be doing so?
Escape characters are part of the shell syntax. They are never special
when they result from expansions, unless they are reinterpreted as shell
input through eval.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
sys/param.h not checked for by configure
Hello all, The header file sys/param.h is not checked for by configure and is not provided by the VMS environment. I have worked around this issue by having the VMS specific build script create an empty substitute file. The HP VMS Engineering team has indicated a willingness to add the sys/param.h file to the operating system in a future release or patch kit, but has a problem. There does not seem to be a standards document as to what exactly should be in this header file. The sys/param.h header file is mentioned at The Open Group web site as existing in some implementations, but I can not find any definition for it. http://pubs.opengroup.org/onlinepubs/009604599/basedefs/sys/stat.h.html is the reference. The Linux System Base navigator shows it as defining two macros for constants by name. I can not find in the Linux system Base definition explorer any description about what those two macros represent in a conforming implementation. It also does not mention the constant value that The Open Group link states could be in that file. http://www.linuxbase.org/navigator/browse/header.php?cmd=displayHid=112 Falling back to a search on general usage gives some views on the two constants of MAXPATHLEN and NOFILE, as being for the maximum size of a file specification and the number of open files, but no references to a standards organization. It did find one post that claimed that the Linux value of 4096 for MAXPATHLEN was wrong, and that it was easy to create longer paths. For current VMS versions, MAXPATHLEN is 4096 and NOFILE is 65535. The actual limit on files is usually set by a quota to that can be retrieved by getdtablesize() and is typically only a few thousand at most, so the NOFILE value is not that useful. MAXPATHLEN appears to be a duplicate for the macros PATH_MAX and FILENAME_MAX that are defined in other standard headers. So does anyone know of a link to a reference standard about what should be in the sys/param.h file. Regards, -John wb8tyw@qsl.network Personal Opinion Only
