❦ 27 May 2020 08:42 -07, Jonathan Nieder:
Because of bug #642922 (archived, but has some interesting discussion),
this patch for this bug ended up being backed out.
> [...]
>> I gather that the ocamlbuild bug has been fixed so can this be
>> reinstated please?
>
> Curious: the
Herbert Xu wrote:
>> Tim Connors wrote:
>>> Because of bug #642922 (archived, but has some interesting discussion),
>>> this patch for this bug ended up being backed out.
[...]
> I gather that the ocamlbuild bug has been fixed so can this be
> reinstated please?
Curious: the ocamlbuild bug
On Sat, Nov 26, 2011 at 07:44:43PM -0600, Jonathan Nieder wrote:
>
> Tim Connors wrote:
>
> > Because of bug #642922 (archived, but has some interesting discussion),
> > this patch for this bug ended up being backed out.
> >
> > Hopefully this bug won't be forgotten by someone who understands
tags 642835 = upstream
block 436466 by 642835
tags 436466 + fixed-upstream
fixed 436466 dash/0.5.7-1
found 436466 dash/0.5.7-2
quit
Tim Connors wrote:
Because of bug #642922 (archived, but has some interesting discussion),
this patch for this bug ended up being backed out.
Hopefully this bug
Hi Gerrit,
The only concern I have with this change is the handling of $PPID
$ cat /tmp/t
echo $PPID
$ sh -c /tmp/t
17254
$ sh -c 'exec /tmp/t'
13318
$
Would this be a regression and, if yes, an acceptable one?
It's a noticeable behavior change and so it should be documented in
the
On Wed, Dec 08, 2010 at 12:10:33AM +0100, Jilles Tjoelker wrote:
Regarding sh -c optimization, I am in favour of this. Uselessly waiting
'sh -c' processes annoy me. I made the change for FreeBSD 8.0 sh, which
is very similar to dash. The SVN changeset is r194128. The change
appears to work for
tags 436466 + patch
forwarded 436466 http://thread.gmane.org/gmane.comp.shells.dash/556
quit
Jilles Tjoelker wrote:
Regarding sh -c optimization, I am in favour of this. Uselessly waiting
'sh -c' processes annoy me. I made the change for FreeBSD 8.0 sh
Thanks.
--
To UNSUBSCRIBE, email to
Drake Wilson wrote:
- Point out that full tail execution optimization is not as
localized as the anything without shell meta-stuff that some
people think it is, and that partial tail execution optimization
can lead to subtle problems if not done carefully. Cf. a vaguely
similar case
Quoth Jonathan Nieder jrnie...@gmail.com, on 2010-11-26 01:10:47 -0600:
Inserting, say, a
debugging echo before the actual command is virtually guaranteed to
not exec the final command directly.
How do you like the ksh93 behavior?
I
Hi Drake,
Drake Wilson wrote:
Depending on how it's implemented, this can also cause a sort of
inconsistency fault line.
[...]
Inserting, say, a
debugging echo before the actual command is virtually guaranteed to
not exec the final command
If this is ever implemented, care should be taken not to break backwards
compatibility. E.g.
$ bash -c 'readlink /proc/$$/exe'
/bin/readlink
$ bash -c ':; readlink /proc/$$/exe'
/bin/bash
$ dash -c 'readlink /proc/$$/exe'
/bin/dash
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org
Package: dash
Version: 0.5.4-1
Severity: wishlist
When you do bash -c foo, where foo is a simple command, it's execed.
It'd be nice if dash had this same optimisation (which should be
rather simpler than it is for bash).
It needn't even be done precisely, i.e. for all cases where it could
be
12 matches
Mail list logo
