On Mon, Sep 21, 2015 at 10:07:55PM +0100, Stephane Chazelas wrote:
> Maybe the test scenario was not clear:
>
> bash -c 'cmd; echo hi'
>
> is run from an interactive shell, cmd is a long running
> application (the problem that sparked this discussion was with
> ping and I showed examples with an
2015-09-22 08:18:08 -0400, Greg Wooledge:
[...]
> You might already have been aware of this; I'm not sure. But in any case,
> it makes a tremendous different what "cmd" is in your example. You
> can't generalize it.
Hi Greg,
Yes, this whole thread is about the behaviour of uninteractive
bash wi
On 9/21/15 5:24 PM, Stephane Chazelas wrote:
> 2015-09-21 15:34:28 -0400, Chet Ramey:
>> On 9/21/15 5:48 AM, Stephane Chazelas wrote:
>>
>>> I'm not sure I prefer that WCE approach over WUE. Wouldn't it be
>>> preferable that applications that intercept SIGINT/QUIT/TSTP for
>>> anything other than
2015-09-22 09:41:35 -0400, Chet Ramey:
[...]
> > AFAICT emacs starts a new process group (and makes it the
> > foreground process group).
>
> Maybe, if it's being run from an interactive shell or in a separate
> X window. On the other hand, run this script with `dash':
>
> echo before
> emacs -n
2015-09-22 09:41:35 -0400, Chet Ramey:
[...]
> > AFAICT emacs starts a new process group (and makes it the
> > foreground process group).
>
> Maybe, if it's being run from an interactive shell or in a separate
> X window. On the other hand, run this script with `dash':
[...]
It does that uncondi
2015-09-22 16:28:16 +0100, Stephane Chazelas:
[...]
> To add on that, the code was removed at some point altogether
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=58eb6cf0f77547d29f4fddca922eb6f98c0ffb28
> in emacs-24.0.96 and then added back without the #ifdef
> BSD_PGRPS
> http://git.sav
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKA
On 9/22/15 11:28 AM, Stephane Chazelas wrote:
> 2015-09-22 15:18:32 +0100, Stephane Chazelas:
>> 2015-09-22 09:41:35 -0400, Chet Ramey:
>> [...]
AFAICT emacs starts a new process group (and makes it the
foreground process group).
>>>
>>> Maybe, if it's being run from an interactive shell
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE
2015-09-22 15:18:32 +0100, Stephane Chazelas:
> 2015-09-22 09:41:35 -0400, Chet Ramey:
> [...]
> > > AFAICT emacs starts a new process group (and makes it the
> > > foreground process group).
> >
> > Maybe, if it's being run from an interactive shell or in a separate
> > X window. On the other ha
On 09/22/2015 08:19 AM, idal...@idallen-fibe.dyndns.org wrote:
> Description:
> Adding a "local" keyword to a variable assignment hides the
> return code of a command substitution. Same problem in both
> bash and dash shells.
>
Not a bug.
$() substition can only affect $? if i
On 09/22/2015 08:22 AM, Daniel Simeone wrote:
>
> Description:
> According to the joint man page for '[' and 'test', '[ --version'
> and '[ --help' should give appropriate output, while 'test' should not.
You're probably reading the coreutils man page, rather than the bash man
page.
Bash
2015-09-22 11:45:20 -0400, Greg Wooledge:
> On Tue, Sep 22, 2015 at 10:19:56AM -0400, idal...@home.idallen.ca wrote:
> > Description:
> > Adding a "local" keyword to a variable assignment hides the
> > return code of a command substitution. Same problem in both
> > bash and dash shells
On Tue, Sep 22, 2015 at 10:19:56AM -0400, idal...@home.idallen.ca wrote:
> Description:
> Adding a "local" keyword to a variable assignment hides the
> return code of a command substitution. Same problem in both
> bash and dash shells.
Yes, this is how it works. If you care abo
On Tue, Sep 22, 2015 at 11:46:05AM -0500, Daniel Simeone wrote:
> When I ran 'which [' it stated that the /usr/bin/[ was what was running,
> and so I presumed it was in bash.
which(1) is an external program, so it doesn't know about shell builtins.
Use "type [" in bash intead. I'm quite fond of
You are correct:
/usr/bin/\[ --help
gives the desired output.
When I ran 'which [' it stated that the /usr/bin/[ was what was running,
and so I presumed it was in bash.
Also, the error message says 'bash'
So, all in all, a bit counfusing.
Cheers,
Daniel
On 22 September 2015 at 10:39, Eric
Greg Wooledge wrote:
> Just for the record, ping is the *classic* example of an incorrectly
> written application that traps SIGINT but doesn't kill itself with
> SIGINT afterward. (This seems to be true on multiple systems -- at
> the very least, HP-UX and Linux pings both suffer from it.)
The c
2015-09-22 12:04:45 -0600, Bob Proulx:
> Greg Wooledge wrote:
> > Just for the record, ping is the *classic* example of an incorrectly
> > written application that traps SIGINT but doesn't kill itself with
> > SIGINT afterward. (This seems to be true on multiple systems -- at
> > the very least, H
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/22/15 11:39 AM, Eric Blake wrote:
> Bash has not (yet) implemented support for ANY --options to its
> builtins
Bash-4.4 has --help for all builtins except for a small set listed in
the manual.
- --
``The lyf so short, the craft so long to ler
19 matches
Mail list logo
