Re: Can someone explain this?

On Sat, Feb 12, 2011 at 4:54 PM, Bob Proulx wrote: > I am a big fan of piping the script to the remote shell. > >  $ echo "cd /tmp && pwd" | ssh example.com bash >  /tmp > > This has two advantages.  One is that you can pick your shell on the > remote host.  Otherwise it runs as whatever is config

Re: Can someone explain this?

Dennis Williamson wrote: > Yes, do your quoting like this: > ssh localhost 'bash -c "cd /tmp; pwd"' I am a big fan of piping the script to the remote shell. $ echo "cd /tmp && pwd" | ssh example.com bash /tmp This has two advantages. One is that you can pick your shell on the remote host.

Re: Can someone explain this?

On Fri, Feb 11, 2011 at 10:28 PM, Jon Seymour wrote: > Ok, so it relates to how ssh interprets its command argument: > > So: > >    bash -c 'cd /tmp ; pwd' > > My expectation was that it would invoke bash with the arguments: > > '-c' > 'cd /tmp; pwd' > > But bash is actually invoked with: > > '-c'

Re: Can someone explain this?

Ok, so it relates to how ssh interprets its command argument: So: bash -c 'cd /tmp ; pwd' My expectation was that it would invoke bash with the arguments: '-c' 'cd /tmp; pwd' But bash is actually invoked with: '-c' 'cd' '/tmp' and then pwd is invoked, presumably in same shell that invoke

Re: Can someone explain this?

On Fri, Feb 11, 2011 at 9:21 PM, Jon Seymour wrote: > Correction - a _leading_ cd command and only a leading cd command, > seems to be completely ignored in the case I described. > > Why is this? > > jon. > > -- Forwarded message -- > From: Jon Seymour > Date: Sat, Feb 12, 2011 at

Re: Can someone explain this?

Correction - a _leading_ cd command and only a leading cd command, seems to be completely ignored in the case I described. Why is this? jon. -- Forwarded message -- From: Jon Seymour Date: Sat, Feb 12, 2011 at 2:18 PM Subject: Can someone explain this? To: bug-bash@gnu.org Can

Can someone explain this?

Can someone explain why this is happening? #expected $ bash -c 'cd /tmp; pwd' /tmp #expected $ bash -c 'pwd; cd /tmp; pwd' /home/jseymour /tmp #expected $ ssh localhost bash -c 'pwd; cd /tmp; pwd' /home/jseymour /tmp #unexpected $ ssh localhost bash -c 'cd /tmp; pwd' /home/jseymour My expectat

Re: Don't show help of `readonly' and `readarray' when I run `help read'

I forgot to reply to all On Fri, Feb 11, 2011 at 11:15 PM, Chet Ramey wrote: > On 2/11/11 3:53 AM, Clark J. Wang wrote: > > > > > > On Thu, Feb 10, 2011 at 10:21 PM, Chet Ramey > > wrote: > > > > On 2/10/11 4:03 AM, Clark J. Wang wrote: > > > help: help [-dms

Re: help's blank lines have four spaces appended

On Fri, Feb 11, 2011 at 11:16 PM, Chet Ramey wrote: > On 2/11/11 4:02 AM, Clark J. Wang wrote: > > On Mon, Feb 7, 2011 at 12:01 AM, Chet Ramey > > wrote: > > > > On 2/6/11 2:01 AM, jida...@jidanni.org > wrote: > > > Why add the fou

Re: [BUG] Bash not reacting to Ctrl-C

On Fri, Feb 11, 2011 at 1:30 PM, Linus Torvalds wrote: > > The other case is that the child process was quick and already exited. > You get ^C, but the child never did. When you do the waitpid(), you'll > never get the EINTR, because there was no actual wait. Ok, so here's a suggested patch. It t

Re: [BUG] Bash not reacting to Ctrl-C

On Fri, Feb 11, 2011 at 1:16 PM, Chet Ramey wrote: > > In the meantime, read Martin Cracauer's description of the issue. > http://www.cons.org/cracauer/sigint.html. This is now the second time in the thread that this has been quoted, but bash doesn't even FOLLOW the recommendations in that web-pa

Re: [BUG] Bash not reacting to Ctrl-C

On 02/11, Chet Ramey wrote: > > In the meantime, read Martin Cracauer's description of the issue. > http://www.cons.org/cracauer/sigint.html. I did. OK, OK, I didn't ;) I stopped the reading immediately after I started to think I understand why you sent me this link. Oleg.

Re: [BUG] Bash not reacting to Ctrl-C

On Fri, Feb 11, 2011 at 12:21 PM, Chet Ramey wrote: > > You do realize that this case is indistinguishable from the original > scenario in question: the child gets the SIGINT, handles it, and exits > successfully (or not).  Have you actually not followed the discussion? Umm. I'm the one who broug

Re: [BUG] Bash not reacting to Ctrl-C

On 2/11/11 4:00 PM, Oleg Nesterov wrote: > On 02/11, Chet Ramey wrote: >> >> You do realize that this case is indistinguishable from the original >> scenario in question: the child gets the SIGINT, handles it, and exits >> successfully (or not). > > I already tried to discuss this, but you didn't

Re: [BUG] Bash not reacting to Ctrl-C

On 02/11, Chet Ramey wrote: > > You do realize that this case is indistinguishable from the original > scenario in question: the child gets the SIGINT, handles it, and exits > successfully (or not). I already tried to discuss this, but you didn't reply ;) See http://www.mail-archive.com/bug-bash@g

Re: [BUG] Bash not reacting to Ctrl-C

On 2/11/11 3:01 PM, Linus Torvalds wrote: > On Fri, Feb 11, 2011 at 8:57 AM, Illia Bobyr > wrote: >> On 2/9/2011 3:57 PM, Linus Torvalds wrote: >>> >>> Here's the scenario: > > I'll quote the scenario again, because you clearly didn't bother to read it. > > Please _READ_ it this time before you

Re: [BUG] Bash not reacting to Ctrl-C

On Fri, Feb 11, 2011 at 8:57 AM, Illia Bobyr wrote: > On 2/9/2011 3:57 PM, Linus Torvalds wrote: >> >> Here's the scenario: I'll quote the scenario again, because you clearly didn't bother to read it. Please _READ_ it this time before you answer, ok? >>   - wait_for() sets wait_sigint_received

Re: [BUG] Bash not reacting to Ctrl-C

On 02/11, Illia Bobyr wrote: > > Do we really need to check wait_sigint_received here? > If the child exits because of SIGINT was indeed received all the > processes on the same terminal will also receive it. Only if SIGINT was sent to pgrp (like ^C sends SIGTERM to the foreground process group).

Re: Don't show help of `readonly' and `readarray' when I run `help read'

On 2/10/11 5:34 PM, Chris F.A. Johnson wrote: > On Thu, 10 Feb 2011, Maarten Billemont wrote: > >> On 10 Feb 2011, at 15:21, Chet Ramey wrote: >>> >>> On 2/10/11 4:03 AM, Clark J. Wang wrote: help: help [-dms] [pattern ...] From my understanding the *pattern* here must be a glob-sty

Re: set -e, braces and compound commands

On 2/10/11 11:08 PM, Daniel Villeneuve wrote: > I'm using GNU bash, version 4.1.2(1)-release (i386-redhat-linux-gnu). > > Following the change of semantics of "set -e" in bash 4,"man bash" seems to > imply that the following script should exit after the for command (from the > text "or one of the

Re: [BUG] Bash not reacting to Ctrl-C

On 2/9/2011 3:57 PM, Linus Torvalds wrote: > [...] > The problem is that > 'set_job_status_and_cleanup()' does that > > if (wait_sigint_received&& (WTERMSIG (child->status) == SIGINT)&& .. > > which just looks totally buggy and racy. There's even a comment about > it in the bash source code,

Re: PS1 expansion of \W incorrect for short paths

On 18 Jan., 04:41, Cameron Hutchison wrote: > 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' >

Re: set -e, braces and compound commands

Daniel Villeneuve writes: > For reference, I've consulted > http://thread.gmane.org/gmane.comp.standards.posix.austin.general/282, > http://thread.gmane.org/gmane.comp.shells.bash.bugs/13465 and > the current public POSIX spec I have access to which still says: > > *-e* >When this option is o