I appreciate the help, Martijn, and I suspect I will find your suggestions
useful in the future, but they do not completely work for us in the present
instance. We are, in part, trying to determine if our script may have lost
its positional parameters because it was invoked by someone else using ".
On 1/10/19 4:52 PM, Jeremy wrote:
> Have you considered reading stdin into a string (if it's one line) or an
> array (if it's more) and using `eval' on it? That obviously works better
> if it's one line, but could be made to work on multiple lines.
>
>
> We are trying to determine if
Op 10-01-19 om 22:52 schreef Jeremy:
> We are trying to determine if the current shell supports passing positional
> arguments to a script sourced by dot (.), and we are trying to do it in a
> way that will work under pretty much any shell. If you can show me how to
> do that with eval, then that
A more reliable way to demonstrate the bug:
cat <(echo echo '$1' 2) | . /dev/stdin yes
Should output "yes 2", and does in bash 4.4.23, but in
bash 3.2.57(1)-release it outputs nothing: the output of cat does not get
sourced.
Reminder, I'm seeking a workaround rather than a patch, to reliably te
Date:Tue, 8 Jan 2019 23:40:40 -0800
From:don fong
Message-ID:
| to me, your suggested wrapper script pattern seems unnatural. i don't
| always want users to have to carry around 2 files (the dottable library and
| the wrapper to dot it in).
Then use the "
Date:Thu, 10 Jan 2019 13:52:59 -0800
From:Jeremy
Message-ID:
ps: (intended to add this in the previous reply and forgot...)
| even though in general I hate
| to ship a script that uses eval.
Why?eval is a prefectly proper and useful part of the
shell, and
Date:Thu, 10 Jan 2019 13:52:59 -0800
From:Jeremy
Message-ID:
| We are trying to determine if the current shell supports passing positional
| arguments to a script sourced by dot (.), and we are trying to do it in a
| way that will work under pretty much any sh
On Thu, Jan 10, 2019 at 11:59 AM Chet Ramey wrote:
> On 1/10/19 2:52 PM, Jeremy wrote:
>
>> This command line should run forever:
>
>
>> i=0; while [ "_$(echo echo '$1' | . /dev/stdin yes)" = "_yes" ]; \
>
> do echo -n .; ((i++)); done; printf "\n%s\n" $i
>
>
>> When I run it, it usually term
On 1/10/19 2:52 PM, Jeremy wrote:
> This bug seems not to be in current versions of bash 4.x, but I have not
> made an exhaustive study. The thing is I do not have control over which
> versions of bash people use to run the script, so I need a workaround. I
> was hoping this was a known bug with a
On Thu, Jan 10, 2019 at 11:38 AM Chet Ramey wrote:
> On 1/10/19 2:36 PM, Jeremy wrote:
> > Agreed there is no likelihood of a patch to 3.2. However, this version of
> > bash still has a significant presence in the wild and this bug is
> breaking
> > an installation script, so I am looking for a P
On Thu, Jan 10, 2019 at 11:36:03AM -0800, Jeremy wrote:
> Agreed there is no likelihood of a patch to 3.2. However, this version of
> bash still has a significant presence in the wild and this bug is breaking
> an installation script, so I am looking for a POSIX-compliant (and works
> under Cygwin)
On 1/10/19 2:36 PM, Jeremy wrote:
> Agreed there is no likelihood of a patch to 3.2. However, this version of
> bash still has a significant presence in the wild and this bug is breaking
> an installation script, so I am looking for a POSIX-compliant (and works
> under Cygwin) alternative that avoi
Agreed there is no likelihood of a patch to 3.2. However, this version of
bash still has a significant presence in the wild and this bug is breaking
an installation script, so I am looking for a POSIX-compliant (and works
under Cygwin) alternative that avoids this bug so the script can be
modified.
On 1/9/19 10:51 PM, Clark Wang wrote:
> Seems like if there's "complete -D" defined then "progcomp_alias" would
> never work. So does it make more sense to make "progcomp_alias" has higher
> priority than "complete -D"?
Maybe. The other side is that `progcomp_alias' only comes into play if you
can
On Thu, Jan 10, 2019 at 12:01:10AM -0800, don fong wrote:
> but on my mac, adding the sleep makes it fail reliably on the first
> iteration.
>
> on my linux machine, it seems to succeed reliably even with the sleep - as
> expected.
That's because the version of bash on Mac OS X is 3.2. Bash 3.2
interesting. it looks like somehow the ". /dev/stdin yes" side isn't
waiting for the "echo echo '$1'" side to write to the pipe.
in theory, you should be able to delay the echo and it should still work...
(sleep 1; echo echo '$1') | . /dev/stdin yes
but on my mac, adding the sleep makes it
16 matches
Mail list logo
