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?
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
Re: ulimit and ssh?
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. -peter Andreas Schwab-2 wrote: > > peter360 writes: > >> That makes sense. So the "feature" is to split all parameters on space >> even >> if they are quoted? > > The feature is that ssh concatenates all remaining arguments to a single > string and passes that to the shell on the remote side. If you want to > preserve any quoting in this process you need to quote them. > > Andreas. > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > "And now for something completely different." > > > > -- View this message in context: http://www.nabble.com/ulimit-and-ssh--tp25262471p25754738.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: ulimit and ssh?
peter360 writes: > That makes sense. So the "feature" is to split all parameters on space even > if they are quoted? The feature is that ssh concatenates all remaining arguments to a single string and passes that to the shell on the remote side. If you want to preserve any quoting in this process you need to quote them. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: ulimit and ssh?
peter360 writes: > In my case, I just got > > $ ssh localhost bash -x -c 'ulimit -a' > unlimited > + ulimit Try ssh -v as Marc wrote. debug1: Sending command: bash -x -c ulimit -a The quotes are lost at this point. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
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?
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?
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")
Re: ulimit and ssh?
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'
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.
Re: ulimit and ssh?
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. > and sshd forks a shell to parse the concatenated command string, > in this case "bash -c ulimit -a".Correct me if I am wrong. On the remote server a $SHELL (specified in /etc/passwd, not necessarly the same shell as on the client machine, a long standing issue with rsh/ssh) parses the arguments /again/. Which means you almost always need two layers of quoting if quoting is needed. One for the local shell. One more for the remote shell. > > echo ulimit -a | ssh localhost bash This style avoids the quoting problem entirely and guarentees that the remote shell is bash regardless of different /etc/passwd configuration. However it does use stdin and it is no longer available for the remote command, if that is important. Useful when it can be used however. Also, my example had a problem. > > ssh localhost "bash -c 'ulimit -a'" I should have added the -n option to ssh so that it wouldn't read from stdin. In the above if used in a script it will read and consume any input that may have been expected for a different command. ssh -n localhost "bash -c 'ulimit -a'" Bob
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: ulimit and ssh?
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
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.
