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
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:
> >
> > [...]
>
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
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
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
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
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
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
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
>
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
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
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?
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:
> > >> >
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
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
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:
>> >
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
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
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
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
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:
>
>
>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
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
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.
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
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
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
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
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
29 matches
Mail list logo