Re: [PATCH] ash: make bash_source command search current directory after PATH
On Tue, Jan 30, 2018 at 4:31 AM, Mike Frysinger wrote: > On 30 Jan 2018 04:00, Denys Vlasenko wrote: >> On Mon, Jan 29, 2018 at 7:50 PM, Mike Frysinger wrote: >> >> I still wonder how on Earth Android filesystem ended up not having >> >> /bin/sh. >> >> No one at Google realized that people are using shell scripts >> >> all over the Unix universe? Or they seriously did not want people >> >> to run non-Android specific stuff on Android, and *wanted* >> >> non-android-tailored shell scripts to fail to execute? >> > >> > i think it's more like you shouldn't be running shell the vast majority of >> > the time. systemd showed the numbers to back this up. >> >> We should remove all shell scripts from e.g. kernel, gcc and busybox >> build machinery. Because systemd. Right. > > i don't know what point you're trying to make, but drop the useless > hyperbole. you asked about runtime Android, not about random dev > packages. No, I did not ask about "runtime Android", whatever that means. Android is a Unix system, not a custom phone OS like it was the case in first generations of phones. It can be used as a general-purpose OS: it is possible to run anything Unixy in it. I personally wanted to build busybox. I run compilers, editors, git and such. It's possible. Or rather, it is possible to run anything Unixy in it _after_ you root it and fix the stupid decisions by Android devs who crippled it with incompatible file system layout for no apparent reason. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
On Mon, 2018-01-29 at 09:16 +0800, Kang-Che Sung wrote: > On Mon, Jan 29, 2018 at 2:51 AM, Bernd Petrovitsch > wrote: > > On Fri, 2018-01-26 at 15:15 +0100, Denys Vlasenko wrote: > > > On Fri, Jan 26, 2018 at 9:34 AM, Paul Otto wrote: > > > > [...] > > > > According to the BASH documentation, the source command should: > > > > Read and execute commands from filename in the current shell > > > > environment > > > > and return the exit status of the last command executed from filename. > > > > If > > > > filename does not contain a slash, filenames in PATH are used to > > > > find the > > > > directory containing filename. The file searched for in PATH need > > > > not be > > > > executable. When bash is not in posix mode, the current > > > > directory is > > > > searched if no file is found in PATH. > > > > > > I wish bash wouldn't introduce gratuitous standard violations. > > > > I see such begaviour more as a security problem - there are good > > reasons not using "." automagically in $PATH (like DOS did .). > > The problem with DOS/Windows is that they prioritize "." (working directory) > over PATH when searching commands, which can cause security problems. > Bash actually considers "." last, which is less of the security threat (unless > you're setting a shell environment when user doesn't even have permission to > adjust $PATH). > > For reference, here is the rationale in POSIX: > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#dot > > "Some older implementations searched the current directory for the [file], > even if the value of [PATH] disallowed it. This behavior was omitted from this > volume of POSIX.1-2008 due to concerns about introducing the susceptibility to > trojan horses that the user might be trying to avoid by leaving _dot_ out of > [PATH]." And good so that the implicit '.' is gone. People can add "." to $PATH anyways if they want. And it may be less risky, if the implicit "." is at the end of $PATH instead of the front, but (at least;-) I mistype commands often enough and the list of aliases/shell functions a la "alias gerp=grep" keeps growing - apparently not only for a better user interface. Kind regards, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
On 30 Jan 2018 04:00, Denys Vlasenko wrote: > On Mon, Jan 29, 2018 at 7:50 PM, Mike Frysinger wrote: > >> I still wonder how on Earth Android filesystem ended up not having /bin/sh. > >> No one at Google realized that people are using shell scripts > >> all over the Unix universe? Or they seriously did not want people > >> to run non-Android specific stuff on Android, and *wanted* > >> non-android-tailored shell scripts to fail to execute? > > > > i think it's more like you shouldn't be running shell the vast majority of > > the time. systemd showed the numbers to back this up. > > We should remove all shell scripts from e.g. kernel, gcc and busybox > build machinery. Because systemd. Right. i don't know what point you're trying to make, but drop the useless hyperbole. you asked about runtime Android, not about random dev packages. plus i was referring to hard general data (replacing shell scripts with compiled programs is proven benefit to boot time), not advocating for systemd. -mike signature.asc Description: Digital signature ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
On Mon, Jan 29, 2018 at 7:50 PM, Mike Frysinger wrote: >> I still wonder how on Earth Android filesystem ended up not having /bin/sh. >> No one at Google realized that people are using shell scripts >> all over the Unix universe? Or they seriously did not want people >> to run non-Android specific stuff on Android, and *wanted* >> non-android-tailored shell scripts to fail to execute? > > i think it's more like you shouldn't be running shell the vast majority of > the time. systemd showed the numbers to back this up. We should remove all shell scripts from e.g. kernel, gcc and busybox build machinery. Because systemd. Right. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
On 29 Jan 2018 18:52, Denys Vlasenko wrote: > On Mon, Jan 29, 2018 at 5:55 PM, Mike Frysinger wrote: > >> >> >> I wish bash wouldn't introduce gratuitous standard violations. > >> >> > > >> >> > bash is its own shell. why can't it introduce its own extensions as > >> >> > it sees > >> >> > fit ? > >> >> > >> >> Because a divergence is not a good thing, especially if it's gratuitous > >> > > >> > this position makes no sense. are you saying that no shell should be > >> > allowed > >> > to extend the syntax however it wants ? every shell out there should > >> > only be > >> > allowed to implement POSIX and nothing else ? > >> > >> The extensions which add some significantly useful functionality are ok. > >> Example: arrays. > >> > >> Changes which don't really add such functionality do more harm than good. > >> Example: "function" keyword in bash made it possible to do this: > > > > in general, i think you're applying 20/20 hindsight to things. it's easy to > > say something is a bad idea years after the fact with experience in hand. > > The general observation that "compatibility is a good thing > and should not be broken just for the fun of it" is very old. > It's _good_ when you move your stuff from system to system, > from distro to distro, from one OS to another and things not break. > Or at least break not too severely. again, 20/20 hindsight. you're applying this to a time when there was no real thing as compatibility: compatible with who ? this other random project that just started a year or two ago ? why are they better ? there were no distros to move between, and every system was custom built. it's why POSIX is such a mess of permission "implementation defined" cases as it tried to bring some level of sanity to different systems. > Unfortunately, every new generation of comp-sci students > needs to learn it the hard way: by breaking it and then feeling the pain. or they come out with something so much better that people move away from the previous thing entirely and it dies. > I still wonder how on Earth Android filesystem ended up not having /bin/sh. > No one at Google realized that people are using shell scripts > all over the Unix universe? Or they seriously did not want people > to run non-Android specific stuff on Android, and *wanted* > non-android-tailored shell scripts to fail to execute? i think it's more like you shouldn't be running shell the vast majority of the time. systemd showed the numbers to back this up. so on a resource constrained system (like Android phones, especially the first ones from over a decade ago), no shell is better as it forces people to use a constrained language. in this case, the init "exec" stuff, or a compiled language like C or C++. https://android.googlesource.com/platform/system/core/+/master/init/README.md -mike signature.asc Description: Digital signature ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
On Mon, Jan 29, 2018 at 5:55 PM, Mike Frysinger wrote: >> >> >> I wish bash wouldn't introduce gratuitous standard violations. >> >> > >> >> > bash is its own shell. why can't it introduce its own extensions as it >> >> > sees >> >> > fit ? >> >> >> >> Because a divergence is not a good thing, especially if it's gratuitous >> > >> > this position makes no sense. are you saying that no shell should be >> > allowed >> > to extend the syntax however it wants ? every shell out there should only >> > be >> > allowed to implement POSIX and nothing else ? >> >> The extensions which add some significantly useful functionality are ok. >> Example: arrays. >> >> Changes which don't really add such functionality do more harm than good. >> Example: "function" keyword in bash made it possible to do this: > > in general, i think you're applying 20/20 hindsight to things. it's easy to > say something is a bad idea years after the fact with experience in hand. The general observation that "compatibility is a good thing and should not be broken just for the fun of it" is very old. It's _good_ when you move your stuff from system to system, from distro to distro, from one OS to another and things not break. Or at least break not too severely. Unfortunately, every new generation of comp-sci students needs to learn it the hard way: by breaking it and then feeling the pain. I still wonder how on Earth Android filesystem ended up not having /bin/sh. No one at Google realized that people are using shell scripts all over the Unix universe? Or they seriously did not want people to run non-Android specific stuff on Android, and *wanted* non-android-tailored shell scripts to fail to execute? ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
On 29 Jan 2018 08:42, Paul Otto wrote: > On Sun, Jan 28, 2018 at 10:43 PM, Mike Frysinger wrote: > > On 28 Jan 2018 19:17, Denys Vlasenko wrote: > > > Making bash "source" behavior non-standard had nothing useful in it. > > > > "source" is already non-standard and not specified in POSIX. so simply by > > using it, your script is not POSIX compliant. > > That is why, incidentally, I wrote my proposed contribution the way I did > initially. In my view, while BASH treats "source" and "." the same, POSIX > doesn't allow for "source" so why not have "source" hold to the BASH > standard and "." hold to the POSIX standard? I definitely caved too quickly > on that point, and wound up with my contribution being swallowed up into a > patch that did the exact opposite of my intent. ¯\_(ツ)_/¯ of course POSIX allows for "source". it would be crazy to have it specify "anything not explicitly permitted in this specification is banned". it does what it does everywhere else: everything not specified is "unspecified" and thus implementations are free to do what they want. although that is a generality. in the specific case of "source", POSIX has carved out that keyword as both reserved and unspecified: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01 meaning that POSIX recognizes that some shells implement it in a semi-consistent manner, but not enough (yet) to standardize it like it has with other builtins. -mike signature.asc Description: Digital signature ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
On 29 Jan 2018 14:41, Denys Vlasenko wrote:
> On Mon, Jan 29, 2018 at 6:43 AM, Mike Frysinger wrote:
> > On 28 Jan 2018 19:17, Denys Vlasenko wrote:
> >> On Fri, Jan 26, 2018 at 7:50 PM, Mike Frysinger wrote:
> >> > On 26 Jan 2018 15:15, Denys Vlasenko wrote:
> >> >> On Fri, Jan 26, 2018 at 9:34 AM, Paul Otto wrote:
> >> >> > This patch restores, and improves upon, expected behavior to BASH
> >> >> > compatibility which was lost beginning with 1.27.0. This was pulled
> >> >> > into
> >> >> > Alpine 3.7 which, in turn was pulled into official Docker images
> >> >> > beginning
> >> >> > with docker:17.12. As a result, a large number of CICD builds that use
> >> >> > "source filename" have broken everywhere.
> >> >> >
> >> >> > According to the BASH documentation, the source command should:
> >> >> > Read and execute commands from filename in the current shell
> >> >> > environment
> >> >> > and return the exit status of the last command executed from
> >> >> > filename. If
> >> >> > filename does not contain a slash, filenames in PATH are used to
> >> >> > find the
> >> >> > directory containing filename. The file searched for in PATH need
> >> >> > not be
> >> >> > executable. When bash is not in posix mode, the current
> >> >> > directory is
> >> >> > searched if no file is found in PATH.
> >> >>
> >> >> I wish bash wouldn't introduce gratuitous standard violations.
> >> >
> >> > bash is its own shell. why can't it introduce its own extensions as it
> >> > sees
> >> > fit ?
> >>
> >> Because a divergence is not a good thing, especially if it's gratuitous
> >
> > this position makes no sense. are you saying that no shell should be
> > allowed
> > to extend the syntax however it wants ? every shell out there should only
> > be
> > allowed to implement POSIX and nothing else ?
>
> The extensions which add some significantly useful functionality are ok.
> Example: arrays.
>
> Changes which don't really add such functionality do more harm than good.
> Example: "function" keyword in bash made it possible to do this:
in general, i think you're applying 20/20 hindsight to things. it's easy to
say something is a bad idea years after the fact with experience in hand.
also, i don't think the function keyword originated in bash. the internet
suggests it originated in the korn shell and was picked up by other shells.
also, i know you know this, but POSIX isn't a spec that leads the real world.
it exists based on the corpus of existing implementations, including new
functions and features. so unless people try out new things and get others
to adopt them, then POSIX isn't going to change either. that includes trying
things that fail.
> f() { echo "Good"; }
> function g { echo "Your script is now not posix compatible,
> congratu-effing-lations"; }
some people like that extra syntatic sugar because it makes scanning code
and identifying functions easier (to their eyes). i've met a few people
now who argue you should always keep the "function" keyword.
-mike
signature.asc
Description: Digital signature
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
Thanks for the heads up, William! Great to hear! Thanks, Paul On Jan 29, 2018 8:49 AM, "William Pitcock" wrote: > Hello, > > On Sat, Jan 27, 2018 at 3:05 PM, Paul Otto wrote: > > Thanks for taking care of this, Denys. It didn't wind up the way I'd > hoped, > > but at least it is predictable both ways now. I will see if there is a > way > > to get Alpine Linux to build with that config option set, to resolve the > > regression introduced by busybox 1.27. > > This is done in 3.7 and edge as busybox-1.27.2-r8. Relevant commit: > https://git.alpinelinux.org/cgit/aports/commit/?id= > fae8e63b4df5c1052fc79ed551d442263ddcb523 > > William > ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
Hello, On Mon, Jan 29, 2018 at 4:42 PM, Paul Otto wrote: > > > >> > Making bash "source" behavior non-standard had nothing useful in it. >> >> "source" is already non-standard and not specified in POSIX. so simply by >> using it, your script is not POSIX compliant. > > > That is why, incidentally, I wrote my proposed contribution the way I did > initially. In my view, while BASH treats "source" and "." the same, POSIX > doesn't allow for "source" so why not have "source" hold to the BASH > standard and "." hold to the POSIX standard? I definitely caved too quickly > on that point, and wound up with my contribution being swallowed up into a > patch that did the exact opposite of my intent. ¯\_(ツ)_/¯ > > This is probably due to the fact that many (for instance, I) expect . and source to behave the same way :) Having them behaving differently would somewhat violate the principle of least surprise :) BR, -- Emmanuel Deloget ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
Hello, On Sat, Jan 27, 2018 at 3:05 PM, Paul Otto wrote: > Thanks for taking care of this, Denys. It didn't wind up the way I'd hoped, > but at least it is predictable both ways now. I will see if there is a way > to get Alpine Linux to build with that config option set, to resolve the > regression introduced by busybox 1.27. This is done in 3.7 and edge as busybox-1.27.2-r8. Relevant commit: https://git.alpinelinux.org/cgit/aports/commit/?id=fae8e63b4df5c1052fc79ed551d442263ddcb523 William ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
I really want to argue that there is a quite simple workaround to get the
bash 'source' behavior you need: Just append ":." to the PATH environment
variable before you run the "." command.
Or this:
source () {
PATH="$PATH:." . "$@"
}
Was there any difficulty of doing it?
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
On Sun, Jan 28, 2018 at 10:43 PM, Mike Frysinger wrote: > On 28 Jan 2018 19:17, Denys Vlasenko wrote: > > On Fri, Jan 26, 2018 at 7:50 PM, Mike Frysinger wrote: > > > On 26 Jan 2018 15:15, Denys Vlasenko wrote: > > >> On Fri, Jan 26, 2018 at 9:34 AM, Paul Otto wrote: > > >> > This patch restores, and improves upon, expected behavior to BASH > > >> > compatibility which was lost beginning with 1.27.0. This was pulled > into > > >> > Alpine 3.7 which, in turn was pulled into official Docker images > beginning > > >> > with docker:17.12. As a result, a large number of CICD builds that > use > > >> > "source filename" have broken everywhere. > > >> > > > >> > According to the BASH documentation, the source command should: > > >> > Read and execute commands from filename in the current shell > environment > > >> > and return the exit status of the last command executed from > filename. If > > >> > filename does not contain a slash, filenames in PATH are used to > find the > > >> > directory containing filename. The file searched for in PATH > need not be > > >> > executable. When bash is not in posix mode, the current > directory is > > >> > searched if no file is found in PATH. > > >> > > >> I wish bash wouldn't introduce gratuitous standard violations. > > > > > > bash is its own shell. why can't it introduce its own extensions as > it sees > > > fit ? > > > > Because a divergence is not a good thing, especially if it's gratuitous > > this position makes no sense. are you saying that no shell should be > allowed > to extend the syntax however it wants ? every shell out there should only > be > allowed to implement POSIX and nothing else ? > > Based on my understanding of the history of these shells, BASH came up with its syntax before the POSIX standard was ratified. So, while BASH came out after sh, it came out *before* this "standard" was established that some hold to so religiously. > > Making bash "source" behavior non-standard had nothing useful in it. > > "source" is already non-standard and not specified in POSIX. so simply by > using it, your script is not POSIX compliant. That is why, incidentally, I wrote my proposed contribution the way I did initially. In my view, while BASH treats "source" and "." the same, POSIX doesn't allow for "source" so why not have "source" hold to the BASH standard and "." hold to the POSIX standard? I definitely caved too quickly on that point, and wound up with my contribution being swallowed up into a patch that did the exact opposite of my intent. ¯\_(ツ)_/¯ ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
On Mon, Jan 29, 2018 at 6:43 AM, Mike Frysinger wrote:
> On 28 Jan 2018 19:17, Denys Vlasenko wrote:
>> On Fri, Jan 26, 2018 at 7:50 PM, Mike Frysinger wrote:
>> > On 26 Jan 2018 15:15, Denys Vlasenko wrote:
>> >> On Fri, Jan 26, 2018 at 9:34 AM, Paul Otto wrote:
>> >> > This patch restores, and improves upon, expected behavior to BASH
>> >> > compatibility which was lost beginning with 1.27.0. This was pulled into
>> >> > Alpine 3.7 which, in turn was pulled into official Docker images
>> >> > beginning
>> >> > with docker:17.12. As a result, a large number of CICD builds that use
>> >> > "source filename" have broken everywhere.
>> >> >
>> >> > According to the BASH documentation, the source command should:
>> >> > Read and execute commands from filename in the current shell
>> >> > environment
>> >> > and return the exit status of the last command executed from filename.
>> >> > If
>> >> > filename does not contain a slash, filenames in PATH are used to
>> >> > find the
>> >> > directory containing filename. The file searched for in PATH need
>> >> > not be
>> >> > executable. When bash is not in posix mode, the current
>> >> > directory is
>> >> > searched if no file is found in PATH.
>> >>
>> >> I wish bash wouldn't introduce gratuitous standard violations.
>> >
>> > bash is its own shell. why can't it introduce its own extensions as it
>> > sees
>> > fit ?
>>
>> Because a divergence is not a good thing, especially if it's gratuitous
>
> this position makes no sense. are you saying that no shell should be allowed
> to extend the syntax however it wants ? every shell out there should only be
> allowed to implement POSIX and nothing else ?
The extensions which add some significantly useful functionality are ok.
Example: arrays.
Changes which don't really add such functionality do more harm than good.
Example: "function" keyword in bash made it possible to do this:
f() { echo "Good"; }
function g { echo "Your script is now not posix compatible,
congratu-effing-lations"; }
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
On 28 Jan 2018 19:17, Denys Vlasenko wrote: > On Fri, Jan 26, 2018 at 7:50 PM, Mike Frysinger wrote: > > On 26 Jan 2018 15:15, Denys Vlasenko wrote: > >> On Fri, Jan 26, 2018 at 9:34 AM, Paul Otto wrote: > >> > This patch restores, and improves upon, expected behavior to BASH > >> > compatibility which was lost beginning with 1.27.0. This was pulled into > >> > Alpine 3.7 which, in turn was pulled into official Docker images > >> > beginning > >> > with docker:17.12. As a result, a large number of CICD builds that use > >> > "source filename" have broken everywhere. > >> > > >> > According to the BASH documentation, the source command should: > >> > Read and execute commands from filename in the current shell > >> > environment > >> > and return the exit status of the last command executed from filename. > >> > If > >> > filename does not contain a slash, filenames in PATH are used to find > >> > the > >> > directory containing filename. The file searched for in PATH need not > >> > be > >> > executable. When bash is not in posix mode, the current > >> > directory is > >> > searched if no file is found in PATH. > >> > >> I wish bash wouldn't introduce gratuitous standard violations. > > > > bash is its own shell. why can't it introduce its own extensions as it sees > > fit ? > > Because a divergence is not a good thing, especially if it's gratuitous this position makes no sense. are you saying that no shell should be allowed to extend the syntax however it wants ? every shell out there should only be allowed to implement POSIX and nothing else ? > Making bash "source" behavior non-standard had nothing useful in it. "source" is already non-standard and not specified in POSIX. so simply by using it, your script is not POSIX compliant. -mike signature.asc Description: Digital signature ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
On Mon, Jan 29, 2018 at 2:51 AM, Bernd Petrovitsch wrote: > On Fri, 2018-01-26 at 15:15 +0100, Denys Vlasenko wrote: >> On Fri, Jan 26, 2018 at 9:34 AM, Paul Otto wrote: > [...] >> > According to the BASH documentation, the source command should: >> > Read and execute commands from filename in the current shell >> > environment >> > and return the exit status of the last command executed from filename. If >> > filename does not contain a slash, filenames in PATH are used to find >> > the >> > directory containing filename. The file searched for in PATH need not >> > be >> > executable. When bash is not in posix mode, the current directory >> > is >> > searched if no file is found in PATH. >> >> I wish bash wouldn't introduce gratuitous standard violations. > > I see such begaviour more as a security problem - there are good > reasons not using "." automagically in $PATH (like DOS did .). > The problem with DOS/Windows is that they prioritize "." (working directory) over PATH when searching commands, which can cause security problems. Bash actually considers "." last, which is less of the security threat (unless you're setting a shell environment when user doesn't even have permission to adjust $PATH). For reference, here is the rationale in POSIX: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#dot "Some older implementations searched the current directory for the [file], even if the value of [PATH] disallowed it. This behavior was omitted from this volume of POSIX.1-2008 due to concerns about introducing the susceptibility to trojan horses that the user might be trying to avoid by leaving _dot_ out of [PATH]." ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
On Fri, 2018-01-26 at 15:15 +0100, Denys Vlasenko wrote: > On Fri, Jan 26, 2018 at 9:34 AM, Paul Otto wrote: [...] > > According to the BASH documentation, the source command should: > > Read and execute commands from filename in the current shell environment > > and return the exit status of the last command executed from filename. If > > filename does not contain a slash, filenames in PATH are used to find the > > directory containing filename. The file searched for in PATH need not be > > executable. When bash is not in posix mode, the current directory is > > searched if no file is found in PATH. > > I wish bash wouldn't introduce gratuitous standard violations. I see such begaviour more as a security problem - there are good reasons not using "." automagically in $PATH (like DOS did .). Kind regards, Bernd PS: POSIX has some stuff in it which actually requires violation. -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
On Fri, Jan 26, 2018 at 7:50 PM, Mike Frysinger wrote: > On 26 Jan 2018 15:15, Denys Vlasenko wrote: >> On Fri, Jan 26, 2018 at 9:34 AM, Paul Otto wrote: >> > This patch restores, and improves upon, expected behavior to BASH >> > compatibility which was lost beginning with 1.27.0. This was pulled into >> > Alpine 3.7 which, in turn was pulled into official Docker images beginning >> > with docker:17.12. As a result, a large number of CICD builds that use >> > "source filename" have broken everywhere. >> > >> > According to the BASH documentation, the source command should: >> > Read and execute commands from filename in the current shell >> > environment >> > and return the exit status of the last command executed from filename. If >> > filename does not contain a slash, filenames in PATH are used to find >> > the >> > directory containing filename. The file searched for in PATH need not >> > be >> > executable. When bash is not in posix mode, the current directory >> > is >> > searched if no file is found in PATH. >> >> I wish bash wouldn't introduce gratuitous standard violations. > > bash is its own shell. why can't it introduce its own extensions as it sees > fit ? Because a divergence is not a good thing, especially if it's gratuitous (i.e. if a particular bashism is not adding any useful functionaluty). Making bash "source" behavior non-standard had nothing useful in it. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
2018年1月28日 上午5:05，"Paul Otto" 寫道： Thanks for taking care of this, Denys. It didn't wind up the way I'd hoped, but at least it is predictable both ways now. I will see if there is a way to get Alpine Linux to build with that config option set, to resolve the regression introduced by busybox 1.27. I wonder when people suggest adding a config option to make "source"/"." command bash-compatible, why aren't they bothered to append the "." directory at the end of $PATH and save the bloat on the shell code. Also, I suggest the new BASH_SOURCE_CURDIR be _one_ config option across both shells, instead of allowing different behaviors of two shells in one binary. And since this is about behavior change and not a feature "extension", I think we have no need for this config option to depend on *_BASH_COMPAT. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
Thanks for taking care of this, Denys. It didn't wind up the way I'd hoped, but at least it is predictable both ways now. I will see if there is a way to get Alpine Linux to build with that config option set, to resolve the regression introduced by busybox 1.27. - Paul ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
I already committed a similar patch to git.
On Fri, Jan 26, 2018 at 5:46 PM, Paul Otto wrote:
> I have modified this patch per your review comments. For what it's worth, I
> went through hush, and found that it still exhibits the BASH non-POSIXy
> behavior. Take a look:
>
> static char *find_in_path(const char *arg)
> {
> ...
> if (sz != 0) {
> ret = xasprintf("%.*s/%s", sz, PATH, arg);
> } else {
> /* We have xxx:: in $PATH,
> * it means "use current dir" */
> ret = xstrdup(arg);
> }
> if (access(ret, F_OK) == 0)
> break;
> ...
>
>
>
> static int FAST_FUNC builtin_source(char **argv)
> {
> ...
> if (!strchr(filename, '/')) {
> arg_path = find_in_path(filename);
> if (arg_path)
> filename = arg_path;
> }
> ...
>
>
>
> shell/ash.c | 26 --
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git i/shell/ash.c w/shell/ash.c
> index 865159d20..c9edce16c 100644
> --- i/shell/ash.c
> +++ w/shell/ash.c
> @@ -60,6 +60,20 @@
> //config: from GNU bash, which allows for alternative command not
> found
> //config: handling.
> //config:
> +//config:config ASH_BASH_NON_POSIX_DOTCMD
> +//config: bool "non-POSIXy dotcmd behavior (ie: . or source
> )"
> +//config: default n
> +//config: depends ASH_BASH_COMPAT
> +//config: help
> +//config: Activates the expected, non-POSIXy behavior BASH follows
> when
> +//config: dotcmd is invoked with either ". " or "source ".
> In
> +//config: BASH, when the dotcmd is combined with a filename without an
> +//config: absolute or relative path specified, the shell first scans
> the
> +//config: environment's PATH, followed by the present working
> directory
> +//config: (PWD). The POSIX-compliant command does NOT scan the present
> +//config: working directory. This option is disabled by default for
> improved
> +//config: speed and security.
> +//config:
> //config:config ASH_JOB_CONTROL
> //config: bool "Job control"
> //config: default y
> @@ -12967,7 +12981,10 @@ find_dot_file(char *name)
> if (strchr(name, '/'))
> return name;
>
> - while ((fullname = path_advance(&path, name)) != NULL) {
> +while ((fullname = path_advance(&path, name)) != NULL) {
> +#if ASH_BASH_NON_POSIX_DOTCMD
> +try_cur_dir:
> +#endif
> if ((stat(fullname, &statb) == 0) && S_ISREG(statb.st_mode))
> {
> /*
> * Don't bother freeing here, since it will
> @@ -12980,7 +12997,12 @@ find_dot_file(char *name)
> }
>
> /* not found in the PATH */
> - ash_msg_and_raise_error("%s: not found", name);
> +#if ASH_BASH_NON_POSIX_DOTCMD
> +fullname = name;
> +goto try_cur_dir;
you can simply "return name" here.
> +#endif
> +/* not found at all */
> +ash_msg_and_raise_error("%s: not found", name);
> /* NOTREACHED */
> }
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
RE: [**EXTERNAL**] Re: [PATCH] ash: make bash_source command search current directory after PATH
>I fought through the bash startup scripts almost 20 years ago in >college, and still have "source .bashrc" in my ~/.bash_profile that >I've >been carrying from system to system ever since :-) >and my PATH has never had '.' in it. Your explanation makes >perfect sense though. My understanding predates bash. :-) But is it correct? I'd have a hard time testing one of THOSE systems now! -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [**EXTERNAL**] Re: [PATCH] ash: make bash_source command search current directory after PATH
On Fri, Jan 26, 2018 at 10:47 AM, Cathey, Jim wrote: > My understanding, from years past, is that "source " (or ". ") > is _exactly_ the same as "", except that it's running in _this_ shell > rather than in a subshell. Thus it is able to affect environment variables > that subsequent commands can inherit, etc. > > If "." is not in your PATH, and you want to source a file that's right > there, you have to ". ./" just as you'd expect. If that's not what > bash is doing, then it's wrong. > > -- Jim > > Your understanding regarding how ". filename" / "source filename" is supposed to execute commands in the file is correct, it reads and executes commands in the *current shell* as opposed to how "./filename" runs a script as an executable file by launching a *new shell*. Regarding your last statement though, just because BASH doesn't adhere to POSIX does not make it "wrong". This is particularly true when it comes to a tool intended to emulate another tool - to change from the expected behavior because it is believed to be "wrong" results in a tool which incorrectly emulates BASH. BASH does many non-POSIX compliant things. It works exactly as documented. - Paul ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
On 1/26/2018 12:47 PM, Cathey, Jim wrote: My understanding, from years past, is that "source " (or ". ") is _exactly_ the same as "", except that it's running in _this_ shell rather than in a subshell. Thus it is able to affect environment variables that subsequent commands can inherit, etc. If "." is not in your PATH, and you want to source a file that's right there, you have to ". ./" just as you'd expect. If that's not what bash is doing, then it's wrong. I fought through the bash startup scripts almost 20 years ago in college, and still have "source .bashrc" in my ~/.bash_profile that I've been carrying from system to system ever since :-) and my PATH has never had '.' in it. Your explanation makes perfect sense though. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
On 26 Jan 2018 15:15, Denys Vlasenko wrote: > On Fri, Jan 26, 2018 at 9:34 AM, Paul Otto wrote: > > This patch restores, and improves upon, expected behavior to BASH > > compatibility which was lost beginning with 1.27.0. This was pulled into > > Alpine 3.7 which, in turn was pulled into official Docker images beginning > > with docker:17.12. As a result, a large number of CICD builds that use > > "source filename" have broken everywhere. > > > > According to the BASH documentation, the source command should: > > Read and execute commands from filename in the current shell environment > > and return the exit status of the last command executed from filename. If > > filename does not contain a slash, filenames in PATH are used to find the > > directory containing filename. The file searched for in PATH need not be > > executable. When bash is not in posix mode, the current directory is > > searched if no file is found in PATH. > > I wish bash wouldn't introduce gratuitous standard violations. bash is its own shell. why can't it introduce its own extensions as it sees fit ? if you want a runtime that doesn't violate POSIX standards, you can already get that with `set -o posix` (among other ways). but it won't turn off bash extensions that don't clash with the standard ... if the bash-specific behavior wasn't useful, then people wouldn't request support for them right ? :) -mike signature.asc Description: Digital signature ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
RE: [**EXTERNAL**] Re: [PATCH] ash: make bash_source command search current directory after PATH
My understanding, from years past, is that "source " (or ". ") is _exactly_ the same as "", except that it's running in _this_ shell rather than in a subshell. Thus it is able to affect environment variables that subsequent commands can inherit, etc. If "." is not in your PATH, and you want to source a file that's right there, you have to ". ./" just as you'd expect. If that's not what bash is doing, then it's wrong. -- Jim ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
On 1/26/2018 9:15 AM, Denys Vlasenko wrote: On Fri, Jan 26, 2018 at 9:34 AM, Paul Otto wrote: According to the BASH documentation, the source command should: Read and execute commands from filename in the current shell environment and return the exit status of the last command executed from filename. If filename does not contain a slash, filenames in PATH are used to find the directory containing filename. The file searched for in PATH need not be executable. When bash is not in posix mode, the current directory is searched if no file is found in PATH. I wish bash wouldn't introduce gratuitous standard violations. But wow, learn something every day... I never knew 'source' searched PATH at all. I thought it just loaded a file with the same semantics as 'open()'. This would be the danger of learning by example instead of reading the manual. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
I have modified this patch per your review comments. For what it's worth, I
went through hush, and found that it still exhibits the BASH non-POSIXy
behavior. Take a look:
static char *find_in_path(const char *arg)
{
...
if (sz != 0) {
ret = xasprintf("%.*s/%s", sz, PATH, arg);
} else {
/* We have xxx:: in $PATH,
* it means "use current dir" */
ret = xstrdup(arg);
}
if (access(ret, F_OK) == 0)
break;
...
static int FAST_FUNC builtin_source(char **argv)
{
...
if (!strchr(filename, '/')) {
arg_path = find_in_path(filename);
if (arg_path)
filename = arg_path;
}
...
shell/ash.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git i/shell/ash.c w/shell/ash.c
index 865159d20..c9edce16c 100644
--- i/shell/ash.c
+++ w/shell/ash.c
@@ -60,6 +60,20 @@
//config: from GNU bash, which allows for alternative command not
found
//config: handling.
//config:
+//config:config ASH_BASH_NON_POSIX_DOTCMD
+//config: bool "non-POSIXy dotcmd behavior (ie: . or source
)"
+//config: default n
+//config: depends ASH_BASH_COMPAT
+//config: help
+//config: Activates the expected, non-POSIXy behavior BASH follows
when
+//config: dotcmd is invoked with either ". " or "source
". In
+//config: BASH, when the dotcmd is combined with a filename without an
+//config: absolute or relative path specified, the shell first scans
the
+//config: environment's PATH, followed by the present working
directory
+//config: (PWD). The POSIX-compliant command does NOT scan the present
+//config: working directory. This option is disabled by default for
improved
+//config: speed and security.
+//config:
//config:config ASH_JOB_CONTROL
//config: bool "Job control"
//config: default y
@@ -12967,7 +12981,10 @@ find_dot_file(char *name)
if (strchr(name, '/'))
return name;
- while ((fullname = path_advance(&path, name)) != NULL) {
+while ((fullname = path_advance(&path, name)) != NULL) {
+#if ASH_BASH_NON_POSIX_DOTCMD
+try_cur_dir:
+#endif
if ((stat(fullname, &statb) == 0) &&
S_ISREG(statb.st_mode)) {
/*
* Don't bother freeing here, since it will
@@ -12980,7 +12997,12 @@ find_dot_file(char *name)
}
/* not found in the PATH */
- ash_msg_and_raise_error("%s: not found", name);
+#if ASH_BASH_NON_POSIX_DOTCMD
+fullname = name;
+goto try_cur_dir;
+#endif
+/* not found at all */
+ash_msg_and_raise_error("%s: not found", name);
/* NOTREACHED */
}
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
On Fri, Jan 26, 2018 at 9:34 AM, Paul Otto wrote: > This patch restores, and improves upon, expected behavior to BASH > compatibility which was lost beginning with 1.27.0. This was pulled into > Alpine 3.7 which, in turn was pulled into official Docker images beginning > with docker:17.12. As a result, a large number of CICD builds that use > "source filename" have broken everywhere. > > According to the BASH documentation, the source command should: > Read and execute commands from filename in the current shell environment > and return the exit status of the last command executed from filename. If > filename does not contain a slash, filenames in PATH are used to find the > directory containing filename. The file searched for in PATH need not be > executable. When bash is not in posix mode, the current directory is > searched if no file is found in PATH. I wish bash wouldn't introduce gratuitous standard violations. > This patch specifically checks for when commandname is "source" This is not how bash behaves. It treats "." and "source" the same. > and only > performs the additional PWD search in that case, and only after it has > neither 1) short-circuited from a /; and 2) not been found somewhere within > the PATH. I think this should be made a config option, off by default. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
