Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
On Thu, May 03, 2001 at 04:36:43PM +0300, Shaul Karl wrote:
[...]
[16:24:46 tmp]$ bash -c 'echo x-${IFS}-x'
x- -x
Ah, something might be wrong with the above tests:
Right. The invoked shell will expand ${IFS} to a string that happens
to be whitespace, then parse the line as an echo command with
arguments x- and -x, and invoke echo accordingly.
bash -c 'echo x-${IFS}-x'
will do what you expect.
Richard Braakman
Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
On Mon, Apr 30, 2001 at 05:44:46PM -0400, Matt Zimmerman wrote: I could read that as requiring that if IFS is unset, then you get spacetabnewline if you inspect its value, NOT the null string. I have to disagree with this interpretation. The sentence above specifies that the shell will behave _as if_ the value of IFS were... (emphasis added). This implies that IFS does not necessarily have any value at all, and its value certainly should not be relied upon. If the intention were to have a default value for the IFS variable, it would have been much more straightforward to say If IFS is not set, the shell will assign it the value... I think the difference here is that they wanted to hide IFS from the output of printenv and the like. So the shell really behaves like IFS was set to spacetabnewline but it is NOT really set. That's what I read into it anyway. cu Torsten pgpaporpttQgp.pgp Description: PGP signature
Re: Bug#95430: acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
Get a clue, Linux does not allow setuid scripts. Irrelevant. Look up IFS in a bugtraq archive. I shan't do your homework for you. I did. And guess what, I didn't find one single exploit regarding this on Linux. Interestingly, I found one exploit that relied on IFS to be set to work. Okay, I'll concede that this exploit is only theoretical on Linux at this time. I feel it should still be fixed. Should a piece of vulnerable software be written for or ported to Linux, it will then not be exploitable. You're the one who doesn't get it. If you are writing shell functions and you need to save the IFS, then you need to save it properly. You don't seem to comprehend the difference between shell *functions* and shell *scripts*. Sorry I misread one of your messages. In any case, your script is still broken. I'm only working around this because a related autoconf breakage (#95447) is very widespread. I stand on my assertion that the script is correct, and the shell is buggy since it fails to follow consensus behavior. However, as you've fixed the bug, I'll let it drop now. zw
Re: Bug#95430: acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
On Wed, 2 May 2001 23:22:29 -0700 Zack Weinberg [EMAIL PROTECTED] wrote: Okay, I'll concede that this exploit is only theoretical on Linux at this time. Remember what was on the L0pht website... L0pht, making the throetical practical since [some year I care not to remember] This probably has absolutely no relevance to this thread, and I probably sound like an idiot, but I decided to send this anyway. Feel free to make fun of me at will. Regards, Alex.
Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
Herbert Xu [EMAIL PROTECTED] writes:
Not only does that show that Solaris 2.6's shell does not set IFS,
windlord:~ printenv IFS
windlord:~ /bin/sh -c 'echo x-${IFS}-x'
x- -x
windlord:~ uname -a
SunOS windlord.stanford.edu 5.6 Generic_105181-19 sun4u sparc SUNW,Ultra-1
Looks set to me, although it appears to be set incorrectly.
Incorrectly? Looks to me the same as with bash:
[16:24:40 tmp]$ printenv IFS
[16:24:46 tmp]$ bash -c 'echo x-${IFS}-x'
x- -x
[16:24:48 tmp]$ bash --version
GNU bash, version 2.05.0(1)-release (i386-pc-linux-gnu)
Copyright 2000 Free Software Foundation, Inc.
[16:27:28 tmp]$
Ah, something might be wrong with the above tests:
[16:35:41 tmp]$ set | grep IFS
IFS=$' \t\n'
[16:35:59 tmp]$
Solaris's /bin/sh isn't a particularly good example, as it's one of the
most completely broken Bourne shells shipped with a modern OS. It doesn't
even try to be POSIX-compliant.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
Shaul Karl [EMAIL PROTECTED]
Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
Shaul Karl [EMAIL PROTECTED] writes:
Russ Allbery [EMAIL PROTECTED] writes:
windlord:~ printenv IFS
windlord:~ /bin/sh -c 'echo x-${IFS}-x'
x- -x
windlord:~ uname -a
SunOS windlord.stanford.edu 5.6 Generic_105181-19 sun4u sparc SUNW,Ultra-1
Looks set to me, although it appears to be set incorrectly.
Incorrectly? Looks to me the same as with bash:
[16:24:40 tmp]$ printenv IFS
[16:24:46 tmp]$ bash -c 'echo x-${IFS}-x'
x- -x
[16:24:48 tmp]$ bash --version
GNU bash, version 2.05.0(1)-release (i386-pc-linux-gnu)
Copyright 2000 Free Software Foundation, Inc.
[16:27:28 tmp]$
Ah, something might be wrong with the above tests:
Maybe you want
sh -c 'echo x-${IFS}-x'
Both Solaris 2.6 /bin/sh and Linux bash seem to have IFS set.
$ /bin/sh -c 'echo x-${IFS}-x'
x-
-x
- Hari
--
Raja R Harinath -- [EMAIL PROTECTED]
When all else fails, read the instructions. -- Cahn's Axiom
Our policy is, when in doubt, do the right thing. -- Roy L Ash
Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
On Thu, May 03, 2001 at 02:30:28PM -0500, Raja R Harinath wrote:
Maybe you want
sh -c 'echo x-${IFS}-x'
Both Solaris 2.6 /bin/sh and Linux bash seem to have IFS set.
$ /bin/sh -c 'echo x-${IFS}-x'
x-
-x
Identical behavior with zsh from unstable here.
--
- -/- - Rahul Jain - -\- -
- -\- http://linux.rice.edu/~rahul -=- mailto:[EMAIL PROTECTED] -/- -
- -/- I never could get the hang of Thursdays. - HHGTTG by DNA -\- -
|--||--||-|--|-|-|-|
Version 11.423.999.220020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
Re: Bug#95430: acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
severity 95430 normal
quit
On Mon, Apr 30, 2001 at 07:48:07PM -0700, Zack Weinberg wrote:
severity 95430 critical
quit
I can keep this up just as long as you can.
Everyone around here knows that I just love this game.
(tests) ... except that ash does honor IFS from the environment. You
realize that this is a gaping security hole, even if IFS is only used
to split the results of expansion? You realize that it is trivial to
break any shell script on the entire machine that way?
Get a clue, Linux does not allow setuid scripts.
Irrelevant. Look up IFS in a bugtraq archive.
I shan't do your homework for you.
I did. And guess what, I didn't find one single exploit regarding this
on Linux. Interestingly, I found one exploit that relied on IFS to be set
to work.
You're the one who doesn't get it. If you are writing shell functions
and you need to save the IFS, then you need to save it properly.
You don't seem to comprehend the difference between shell *functions*
and shell *scripts*.
Sorry I misread one of your messages.
In any case, your script is still broken. I'm only working around this
because a related autoconf breakage (#95447) is very widespread.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
Zack Weinberg [EMAIL PROTECTED] wrote:
in the environment, and which postdates 4.4BSD and SVR4, and I'll shut
up. The burden is on you to do this. I believe I have adequately
Well thanks to a bug in Netscape, I went to its search page instead of
whatever I was trying to open, and the my cut-and-paste buffer happend
to have IFS code in it:
http://sources.redhat.com/ml/autoconf/2000-03/msg00199.html
Not only does that show that Solaris 2.6's shell does not set IFS, it also
shows that the current autoconf breakage doesn't go back to 1999 as some
have claimed.
I guess this is what they call serendipity.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
Herbert Xu [EMAIL PROTECTED] writes:
Not only does that show that Solaris 2.6's shell does not set IFS,
windlord:~ printenv IFS
windlord:~ /bin/sh -c 'echo x-${IFS}-x'
x- -x
windlord:~ uname -a
SunOS windlord.stanford.edu 5.6 Generic_105181-19 sun4u sparc SUNW,Ultra-1
Looks set to me, although it appears to be set incorrectly.
Solaris's /bin/sh isn't a particularly good example, as it's one of the
most completely broken Bourne shells shipped with a modern OS. It doesn't
even try to be POSIX-compliant.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
reopen 95420 quit ... On Fri, Apr 27, 2001 at 12:22:18AM -0700, Zack Weinberg wrote: ash 0.3.8-1 incorporates changes in word splitting which break common shell scripts, such as /usr/bin/mktexpk and the 'mklibgcc' script used when compiling GCC. #! /bin/ash OIFS=$IFS IFS=, set `echo fnord,a,b,c` IFS=$OIFS CMD=echo $@ $CMD Sorry, but this is broken. This assumes that IFS is set to begin with which may not be the case. I have consulted the Single Unix Standard and can find only dubious justification for this assertion. It never flat out says whether IFS is to be set on entry to the shell or not. However, I note this paragraph: # IFS #Input field separators: a string treated as a list of characters #that is used for field splitting and to split lines into fields #with the read command. If IFS is not set, the shell will behave #as if the value of IFS were the space, tab and newline #characters. (See Field Splitting .) I could read that as requiring that if IFS is unset, then you get spacetabnewline if you inspect its value, NOT the null string. In any case, your change is a gratuitous divergence from the upstream code and a deliberate breakage of consensus shell behavior. My script functions correctly with every Bourne-descended shell I have access to except ash 0.3.8-1. (In addition to bash, pdksh, and previous versions of ash, I tried the /bin/sh provided by Solaris, HP-UX, IRIX, and Digital Unix, and the /bin/ksh and /usr/xpg4/bin/sh provided by Solaris.) Irrespective of what the standard says, you cannot introduce changes into /bin/sh which make it behave differently from every other shell out there. Especially if they have the potential to break every shell script which uses some feature. I had hoped that you had learned your lesson from the last time you pulled a stunt like this. It seems I was wrong. zw
Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
Zack Weinberg [EMAIL PROTECTED] wrote:
On Fri, Apr 27, 2001 at 12:22:18AM -0700, Zack Weinberg wrote:
ash 0.3.8-1 incorporates changes in word splitting which break common
shell scripts, such as /usr/bin/mktexpk and the 'mklibgcc' script used
when compiling GCC.
#! /bin/ash
OIFS=$IFS
IFS=,
set `echo fnord,a,b,c`
IFS=$OIFS
CMD=echo $@
$CMD
Sorry, but this is broken. This assumes that IFS is set to begin with
which may not be the case.
I have consulted the Single Unix Standard and can find only dubious
justification for this assertion. It never flat out says whether IFS
is to be set on entry to the shell or not. However, I note this
paragraph:
It's wrong regardless of whether the shell sets it. The whole point of
saving IFS is so that you can restore it to its original value, which can
be whatever the previous user has set it to, including the case of it not
being set at all. If your code can't handle that, then please don't save
the value at all.
BTW, there is a shorter way of saving it:
OIFS=${IFS-
# IFS
#Input field separators: a string treated as a list of characters
#that is used for field splitting and to split lines into fields
#with the read command. If IFS is not set, the shell will behave
#as if the value of IFS were the space, tab and newline
#characters. (See Field Splitting .)
I could read that as requiring that if IFS is unset, then you get
spacetabnewline if you inspect its value, NOT the null string.
I think this is stretching it a bit. Please try this in any shell:
unset IFS
echo ${IFS+yes}
If you get yes from any shell, then you might have a point. I've certainly
never seen one that hehaved like that.
In any case, your change is a gratuitous divergence from the upstream
code and a deliberate breakage of consensus shell behavior. My script
functions correctly with every Bourne-descended shell I have access to
except ash 0.3.8-1. (In addition to bash, pdksh, and previous
versions of ash, I tried the /bin/sh provided by Solaris, HP-UX, IRIX,
and Digital Unix, and the /bin/ksh and /usr/xpg4/bin/sh provided by
Solaris.) Irrespective of what the standard says, you cannot
introduce changes into /bin/sh which make it behave differently from
every other shell out there. Especially if they have the potential to
break every shell script which uses some feature.
I can understand how frustrating it is to have your scripts broken by
this. But the fact remains that it's the scripts that are broken, not the
shell.
Are your functions supposed to be called by other scripts in general? If
so, then it's particularly important to handle the case of an unset IFS.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
On Mon, Apr 30, 2001 at 12:16:16PM -0700, Zack Weinberg wrote: [whose words are these? unattributed in your mail] Sorry, but this is broken. This assumes that IFS is set to begin with which may not be the case. I have consulted the Single Unix Standard and can find only dubious justification for this assertion. It never flat out says whether IFS is to be set on entry to the shell or not. However, I note this paragraph: # IFS #Input field separators: a string treated as a list of characters #that is used for field splitting and to split lines into fields #with the read command. If IFS is not set, the shell will behave #as if the value of IFS were the space, tab and newline #characters. (See Field Splitting .) I could read that as requiring that if IFS is unset, then you get spacetabnewline if you inspect its value, NOT the null string. I have to disagree with this interpretation. The sentence above specifies that the shell will behave _as if_ the value of IFS were... (emphasis added). This implies that IFS does not necessarily have any value at all, and its value certainly should not be relied upon. If the intention were to have a default value for the IFS variable, it would have been much more straightforward to say If IFS is not set, the shell will assign it the value... Of course, it seems that this behavior is different from that of traditional Bourne shell implementations, so I think I have to agree that ash should avoid diverging from tradition in order to adhere to a relatively new standard. -- - mdz
Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
Matt Zimmerman [EMAIL PROTECTED] wrote:
Of course, it seems that this behavior is different from that of traditional
Bourne shell implementations, so I think I have to agree that ash should avoid
diverging from tradition in order to adhere to a relatively new standard.
I will probably change it back in the next release due to all the autoconf
breakage. However, it still remains that these scripts need to be fixed
since their caller can also unset IFS.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bug#95420: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
This thread is directed at the wrong bug number - the discussion is about #95430, but the messages are going to #95420. Please adjust the recipients appropriately in your replies. -Ben - Original Message - From: Zack Weinberg [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; debian-devel@lists.debian.org Sent: Monday, April 30, 2001 3:16 PM Subject: Bug#95420: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts) reopen 95420 quit ... On Fri, Apr 27, 2001 at 12:22:18AM -0700, Zack Weinberg wrote: ash 0.3.8-1 incorporates changes in word splitting which break common shell scripts, such as /usr/bin/mktexpk and the 'mklibgcc' script used when compiling GCC. #! /bin/ash OIFS=$IFS IFS=, set `echo fnord,a,b,c` IFS=$OIFS CMD=echo $@ $CMD Sorry, but this is broken. This assumes that IFS is set to begin with which may not be the case. I have consulted the Single Unix Standard and can find only dubious justification for this assertion. It never flat out says whether IFS is to be set on entry to the shell or not. However, I note this paragraph: # IFS #Input field separators: a string treated as a list of characters #that is used for field splitting and to split lines into fields #with the read command. If IFS is not set, the shell will behave #as if the value of IFS were the space, tab and newline #characters. (See Field Splitting .) I could read that as requiring that if IFS is unset, then you get spacetabnewline if you inspect its value, NOT the null string. In any case, your change is a gratuitous divergence from the upstream code and a deliberate breakage of consensus shell behavior. My script functions correctly with every Bourne-descended shell I have access to except ash 0.3.8-1. (In addition to bash, pdksh, and previous versions of ash, I tried the /bin/sh provided by Solaris, HP-UX, IRIX, and Digital Unix, and the /bin/ksh and /usr/xpg4/bin/sh provided by Solaris.) Irrespective of what the standard says, you cannot introduce changes into /bin/sh which make it behave differently from every other shell out there. Especially if they have the potential to break every shell script which uses some feature. I had hoped that you had learned your lesson from the last time you pulled a stunt like this. It seems I was wrong. zw
Re: Bug#95420: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
On Mon, Apr 30, 2001 at 06:34:19PM -0400, Ben Darnell wrote: This thread is directed at the wrong bug number - the discussion is about #95430, but the messages are going to #95420. Please adjust the recipients appropriately in your replies. My apologies, I mistyped the bug number. zw
Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
[EMAIL PROTECTED] on Tue, May 01, 2001 at 07:30:14AM +1000 # Let's try this again reopen 95430 severity 95430 critical retitle 95430 [SECURITY] ash honors IFS in environment quit On Tue, May 01, 2001 at 07:30:14AM +1000, Herbert Xu wrote: I have consulted the Single Unix Standard and can find only dubious justification for this assertion. It never flat out says whether IFS is to be set on entry to the shell or not. However, I note this paragraph: It's wrong regardless of whether the shell sets it. The whole point of saving IFS is so that you can restore it to its original value, which can be whatever the previous user has set it to, including the case of it not being set at all. If your code can't handle that, then please don't save the value at all. Uh, no it can't. I'm talking about self-contained shell scripts, not functions. IFS does not inherit through the environment. Self-contained scripts can count on its being set to spacetabnewline when execution begins. (tests) ... except that ash does honor IFS from the environment. You realize that this is a gaping security hole, even if IFS is only used to split the results of expansion? You realize that it is trivial to break any shell script on the entire machine that way? Both 0.3.8 and 0.3.7-x are affected by *that* bug, incidentally. [...] In any case, your change is a gratuitous divergence from the upstream code and a deliberate breakage of consensus shell behavior. My script functions correctly with every Bourne-descended shell I have access to except ash 0.3.8-1. (In addition to bash, pdksh, and previous versions of ash, I tried the /bin/sh provided by Solaris, HP-UX, IRIX, and Digital Unix, and the /bin/ksh and /usr/xpg4/bin/sh provided by Solaris.) Irrespective of what the standard says, you cannot introduce changes into /bin/sh which make it behave differently from every other shell out there. Especially if they have the potential to break every shell script which uses some feature. I can understand how frustrating it is to have your scripts broken by this. But the fact remains that it's the scripts that are broken, not the shell. Are your functions supposed to be called by other scripts in general? If so, then it's particularly important to handle the case of an unset IFS. You don't get it, do you? What the standard says is IRRELEVANT. You cannot change consensus shell behavior even if it is in direct conflict with the standard. Find me ONE other implementation of a Bourne shell, which does not set IFS to spacetabnewline on initialization, ignoring the value in the environment, and which postdates 4.4BSD and SVR4, and I'll shut up. The burden is on you to do this. I believe I have adequately demonstrated what the proper behavior is. zw
Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
Zack Weinberg [EMAIL PROTECTED] writes: Uh, no it can't. I'm talking about self-contained shell scripts, not functions. IFS does not inherit through the environment. Self-contained scripts can count on its being set to spacetabnewline when execution begins. Says who? SUS says: IFS Input field separators : a string treated as a list of characters that is used for field splitting and to split lines into words with the read command. See Field Splitting . If IFS is not set, the shell behaves as if the value of IFS were the space, tab and newline characters. Implementations may ignore the value of IFS in the environment at the time sh is invoked, treating IFS as if it were not set. That seems to indicate that sh is not required to ignore IFS in the environment. -- Alan Shutko [EMAIL PROTECTED] - In a variety of flavors! In specifications, Murphy's Law supersedes Ohm's.
Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
severity 95430 wishlist
quit
On Mon, Apr 30, 2001 at 06:35:53PM -0700, Zack Weinberg wrote:
(tests) ... except that ash does honor IFS from the environment. You
realize that this is a gaping security hole, even if IFS is only used
to split the results of expansion? You realize that it is trivial to
break any shell script on the entire machine that way?
Get a clue, Linux does not allow setuid scripts.
What the standard says is IRRELEVANT. You cannot change consensus
shell behavior even if it is in direct conflict with the standard.
You're the one who doesn't get it. If you are writing shell functions
and you need to save the IFS, then you need to save it properly.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
severity 95430 critical quit I can keep this up just as long as you can. ... (tests) ... except that ash does honor IFS from the environment. You realize that this is a gaping security hole, even if IFS is only used to split the results of expansion? You realize that it is trivial to break any shell script on the entire machine that way? Get a clue, Linux does not allow setuid scripts. Irrelevant. Look up IFS in a bugtraq archive. I shan't do your homework for you. What the standard says is IRRELEVANT. You cannot change consensus shell behavior even if it is in direct conflict with the standard. You're the one who doesn't get it. If you are writing shell functions and you need to save the IFS, then you need to save it properly. You don't seem to comprehend the difference between shell *functions* and shell *scripts*. zw
Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
Zack Weinberg [EMAIL PROTECTED] writes: Irrelevant. Look up IFS in a bugtraq archive. I shan't do your homework for you. You're reporting a bug. The standards say this isn't a requirement or a problem. Prove your case or at least take it to private email. There are billions and billions of ways you can tweak environment variables to break shell scripts that don't bother. What's your point? If I can tweak IFS to change parsing, I can also tweak PATH. -- Alan Shutko [EMAIL PROTECTED] - In a variety of flavors! Please take note:
Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
Alan Shutko [EMAIL PROTECTED] writes: There are billions and billions of ways you can tweak environment variables to break shell scripts that don't bother. What's your point? If I can tweak IFS to change parsing, I can also tweak PATH. So far, all I've come up with are programs passing unvalidated and untrusted info to scripts... but there was a mention of Solaris sh no longer accepting IFS from scripts. -- Alan Shutko [EMAIL PROTECTED] - In a variety of flavors! To be or not to be, that is the bottom line.
