Re: ulimit and ssh?
Thanks Bob. All the explanation were very helpful. Now I feel I have a good understanding of this little peculiarity of ssh. I agree with you that avoiding quoting altogether is simpler. But I am curious guy and learning for the sake of better understanding is also important to me. Bob Proulx wrote: peter360 wrote: Thanks Adreas. That was what I suspected in my reply to Bob. But Bob disagreed. Looks like there were some confusion about this feature even among experts. Seems another reason to deprecate the feature. I don't think anything I said disagreed with what Andreas said. It is just confusing you since we are talking about different points in the process. What does the local shell do, what does the ssh do, what does the remote shell do, what is the end-to-end effect and so forth. All three processes are handling the arguments and each has an affect at different points in the timeline. I was talking end-to-end (shell-ssh-shell) and Andreas was talking about ssh. And by the way but this feature can't really be changed or it would break twenty years or so of scripts which rely upon the existing behavior. Greg Wooledge wrote: imadev:~$ $HOME/bin/args 'ulimit -a' 1 args: 'ulimit -a' imadev:~$ remsh localhost $HOME/bin/args 'ulimit -a' 2 args: 'ulimit' '-a' imadev:~$ ssh localhost $HOME/bin/args 'ulimit -a' wool...@localhost's password: 2 args: 'ulimit' '-a' Nice! It would also be illustrative to show what happens without any quoting and with quoting for two shell layers. $ $HOME/bin/show-args 'ulimit -a' arg1: ulimit -a $ ssh -n localhost $HOME/bin/show-args ulimit -a arg1: ulimit arg2: -a $ ssh -n localhost $HOME/bin/show-args 'ulimit -a' arg1: ulimit arg2: -a $ ssh -n localhost $HOME/bin/show-args 'ulimit -a' arg1: ulimit -a Since there are two shells splitting words in the end-to-end result then the effect is that you need to quote your arguments twice in order to have an argument containing whitespace in one argument by the time it has been processed through two shell's argument processing. Without sufficient quoting you have this following case, which isn't what you want. The bash shell on the remote end would not see args -c ulimit -a but would see -a as a separate $ ssh -n localhost $HOME/bin/show-args bash -c ulimit -a arg1: bash arg2: -c arg3: ulimit arg4: -a That isn't what you want. You need to quote the args twice. $ ssh -n localhost $HOME/bin/show-args 'bash -c ulimit -a' arg1: bash arg2: -c arg3: ulimit -a In the end you want something like this: $ ssh -n localhost 'bash -c ulimit -a' core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-I) 8185 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 8185 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited However I think it is simpler to avoid the argument processing and instead using stdin to the shell. $ echo ulimit -a | ssh localhost bash Isn't that simpler? Bob -- View this message in context: http://old.nabble.com/ulimit-and-ssh--tp25262471p27086055.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: ulimit and ssh?
That makes sense. So the feature is to split all parameters on space even if they are quoted? I would vote to remove this feature in ssh. Thanks for the explanation. Greg Wooledge wrote: On Tue, Sep 08, 2009 at 11:39:02AM -0700, peter360 wrote: Thanks for the explanation. So my understanding of the way ssh works is still incorrect. I am confused about at which point the two parameters, -c and ulimit -a were converted into three, -c, ulimit, and -a. I guess I need to read the source of ssh and bash to really understand this... It's an ssh feature for backward compatibility with remsh/rsh. imadev:~$ $HOME/bin/args 'ulimit -a' 1 args: 'ulimit -a' imadev:~$ remsh localhost $HOME/bin/args 'ulimit -a' 2 args: 'ulimit' '-a' imadev:~$ ssh localhost $HOME/bin/args 'ulimit -a' wool...@localhost's password: 2 args: 'ulimit' '-a' -- View this message in context: http://www.nabble.com/ulimit-and-ssh--tp25262471p25530173.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: ulimit and ssh?
In my case, I just got $ ssh localhost bash -x -c 'ulimit -a' unlimited + ulimit Not very informative. Marc Herbert-6 wrote: peter360 a écrit : Thanks for the explanation. So my understanding of the way ssh works is still incorrect. I am confused about at which point the two parameters, -c and ulimit -a were converted into three, -c, ulimit, and -a. I guess I need to read the source of ssh and bash to really understand this... Enabling tracing options usually helps a lot. Instead of this: sshlocalhost bash-c 'ulimit -a' Try this: ssh -v localhost bash -x -c 'ulimit -a' (And as usual, check out the Guide to unix shell quoting) -- View this message in context: http://www.nabble.com/ulimit-and-ssh--tp25262471p25530174.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: ulimit and ssh?
Bob, Thanks for the explanation. So my understanding of the way ssh works is still incorrect. I am confused about at which point the two parameters, -c and ulimit -a were converted into three, -c, ulimit, and -a. I guess I need to read the source of ssh and bash to really understand this... Bob Proulx wrote: peter360 wrote: So, just to make sure I really understand this, here is how I understand ssh worked: even thought I gave the command bash -c 'ulimit -a' as 3 separate strings, Yes. ssh (either the client or the server) actually concatenate them into one, No. It isn't put into one string unless you quote it as one string. -- View this message in context: http://www.nabble.com/ulimit-and-ssh--tp25262471p25351813.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
ulimit and ssh?
Can someone explain this to me? Why am I not seeing correct results from ulimit after ssh into localhost? Thanks! $ ssh localhost bash -c 'ulimit -a' unlimited but $ bash -c 'ulimit -a' core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 32768 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 1024 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited -- View this message in context: http://www.nabble.com/ulimit-and-ssh--tp25262471p25262471.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: ulimit and ssh?
Bob, Thanks for the quick reply! A local unix guru also told me the same thing. So, just to make sure I really understand this, here is how I understand ssh worked: even thought I gave the command bash -c 'ulimit -a' as 3 separate strings, ssh (either the client or the server) actually concatenate them into one, and sshd forks a shell to parse the concatenated command string, in this case bash -c ulimit -a.Correct me if I am wrong. Glad I learned something new. Bob Proulx wrote: peter360 wrote: Can someone explain this to me? Why am I not seeing correct results from ulimit after ssh into localhost? Thanks! $ ssh localhost bash -c 'ulimit -a' unlimited You have insufficiently quoted your argument to ssh. This is causing bash not to get ulimit -a but to get ulimit -a instead. You are seeing the output of ulimit. Try this: ssh localhost bash -c 'ulimit -a' And this: echo ulimit -a | ssh localhost bash Bob -- View this message in context: http://www.nabble.com/ulimit-and-ssh--tp25262471p25263766.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: wrong lineno inside trap?
Chet Ramey wrote: Bash-4.0 should behave better in this area, but quoted strings will always cause unpredictable values for $LINENO. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/ Thanks for the explanation. -- View this message in context: http://www.nabble.com/wrong-lineno-inside-trap--tp21383479p21472277.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
wrong lineno inside trap?
I wrote a test program test.sh: trap ' echo this is line 3, but LINENO=$LINENO ' 0 echo this is line 7, and LINENO=$LINENO --- when I ran it I got $ sh /tmp/test.sh this is line 7, and LINENO=7 this is line 3, but LINENO=11 My bash version is $ sh --version GNU bash, version 3.2.25(1)-release (x86_64-redhat-linux-gnu) Copyright (C) 2005 Free Software Foundation, Inc. Is this a known problem? Thanks. -- View this message in context: http://www.nabble.com/wrong-lineno-inside-trap--tp21383479p21383479.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
login shell or not?
In an interative shell, what is the easiest way to tell whether it is a login shell or not? Thanks. -- View this message in context: http://www.nabble.com/login-shell-or-not--tf3211932.html#a8919535 Sent from the Gnu - Bash mailing list archive at Nabble.com. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
