similar to: Why are the arguments supplied for the command run through ssh interpreted by shell before they are passed to the command on the server side?

On Sun, 12 Jan 2020, Yuri wrote: > This was English, not German, BTW. For some values of English, perhaps. > You would lose the ability to redirect I/O in an immediate way, but you would > always be able to run a shell command like "/bin/sh" "-c" "any-command | tee > cmd.log | process-further" which would regain the ability to do everything > that a

On Sun, 12 Jan 2020, Yuri wrote: > dedicated argument, for example -z. The specification can be like this: The wording could need some translation by a native speaker, but the idea of this feature request is certainly sound. Of course you?d lose the ability to run multiple commands, redirect I/O, etc. when using your proposed flag. bye, //mirabilos -- tarent solutions GmbH Rochusstra?e

On 2020-01-11 08:57, Thorsten Glaser wrote: > If you wish for no local expansion, quote locally, such as: > > ssh -l luser remotehost ' > command1 > command2 > ? > ' This didn't work for me because single quotes only prevent local expansion. The string is expanded on the remote host. Yuri

On 2020-01-11 01:38, Darren Tucker wrote: > The command you give is always handled on the server by your shell in some > fashion. It has to be, because SSH only specifies an opaque string for the > remote command, so without doing so you would not be able to specify > arguments at all. It's not obvious why does it have to be this way. ssh sends the command as an array of

I do think it's a problem that, as far as I can see, the exact behaviour of ssh command interpretation isn't explained anywhere in its man pages, even though it seems like the only possibility if you understand the protocol. ssh(1) just says "If command is specified, it is executed on the remote host instead of a login shell", but that doesn't provide any hint about what

On Tue, 2 Dec 2014, H. Peter Anvin wrote: > This is the default unless the "quiet" option is set. Hmm. tglaser at luna:/srv/tftp $ fgrep -ri quiet . Binary file ./hdt.c32 matches Binary file ./ldlinux.c32 matches Binary file ./vmlinuz matches Binary file ./linux.c32 matches Binary file ./debian-installer/jessie/amd64/linux matches Binary file ./debian-installer/jessie/i386/linux

I conjecture that only few of the existing use cases rely on remote expansion. In any case (no pun intended), IMHO it would be better to break a few of the current use cases but leave the majority functional - than kill scp for all. Regards, Uri > On Aug 3, 2020, at 02:50, Jakub Jelen <jjelen at redhat.com> wrote: > > ?On Sat, 2020-08-01 at 00:17 +0000, Blumenthal, Uri - 0553

Hi, I still have the question: when I have an environment that uses vesamenu, for example on PXE, how do I configure it so that, for some of the menu entries, it switches back to the text mode (03h) before handing off to the next bootloader / kernel? Thanks, //mirabilos -- tarent solutions GmbH Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/ Tel: +49 228 54881-393 ? Fax: +49 228

On Fri, 26 May 2023, Mingye Wang (Artoria2e5) wrote: > ssh(1) currently affords an argument-passing functionality, but as the manpage > states, all arguments are simply concatenated by space. How else would it do that? The arguments are processed by the shell first then passed as an array of NUL-terminated strings. > The modest proposal is that we put a giant CAVEATS section in the

On 27/05/2023 01:45, Thorsten Glaser wrote: >> ssh user at host "ls -l a\ b" > This one, incidentally, sends 'ls -l a b' to the remote shell. > ssh user at host "ls -l a\\ b" > has the effect you want; the first backslash is eaten by the > local shell. > Or is it? $ echo "ls -l a\ b" ls -l a\ b $ This is with bash 5.2.15. From the

On Sat, May 27, 2023 at 02:45:34AM +0200, Thorsten Glaser <t.glaser at tarent.de> wrote: > On Sat, 27 May 2023, raf wrote: > > >So, perhaps this could be added to the existing > >sentence/paragraph: > > > > "so any spaces in individual arguments must be > > Must they? No, a single space will do just fine. They do if you want the receiving shell

Hi, ssh(1) currently affords an argument-passing functionality, but as the manpage states, all arguments are simply concatenated by space. This behavior is non-obvious for those reading only the synopsis: one would expect something that takes argv input to somehow preserve the argument boundary and not, say, let a semicolon ruin all the fun. This is probably old news for all of you. I have

Ah, depends on the image type. We spoke reset for an NBP though. On December 3, 2014 12:50:24 AM PST, Thorsten Glaser <t.glaser at tarent.de> wrote: >On Tue, 2 Dec 2014, H. Peter Anvin wrote: > >> This is the default unless the "quiet" option is set. > >Hmm. > >tglaser at luna:/srv/tftp $ fgrep -ri quiet . >Binary file ./hdt.c32 matches >Binary file

On Sat, 27 May 2023, raf wrote: >So, perhaps this could be added to the existing >sentence/paragraph: > > "so any spaces in individual arguments must be Must they? No, a single space will do just fine. > quoted using the syntax of the destination > user's login shell". ? keeping in mind the source shell?s quoting as well. >If an example were needed,

On Sat, May 27, 2023 at 12:08:43AM +0200, Thorsten Glaser <t.glaser at tarent.de> wrote: > On Fri, 26 May 2023, Mingye Wang (Artoria2e5) wrote: > > > ssh(1) currently affords an argument-passing functionality, but as the manpage > > states, all arguments are simply concatenated by space. > > How else would it do that? The arguments are processed by the > shell

On 27.05.23 00:08, Thorsten Glaser wrote: > On Fri, 26 May 2023, Mingye Wang (Artoria2e5) wrote: >> The less modest one is we throw out the "[argument ...]" part altogether. It > > Absolutely not. This will break about all uses of ssh in existence. You are confusing "ssh(1) does (not) distinguish between 'command' and 'argument(s)'" with

On Dec 3, 2014 3:54 AM, "Thorsten Glaser" <t.glaser at tarent.de> wrote: > > On Tue, 2 Dec 2014, H. Peter Anvin wrote: > > > This is the default unless the "quiet" option is set. > > Hmm. > It does not switch back to text mode when chaining to > https://www.mirbsd.org/MirOS/current/i386/boot renamed > to "pxebsd.0" (used to be

On 12/02/2014 06:48 AM, Thorsten Glaser wrote: > Hi, > > I still have the question: when I have an environment that uses > vesamenu, for example on PXE, how do I configure it so that, for > some of the menu entries, it switches back to the text mode (03h) > before handing off to the next bootloader / kernel? > This is the default unless the "quiet" option is set.

On Thu, Dec 4, 2014 at 8:45 AM, Ady <ady-sf at hotmail.com> wrote: > >> On Thu, 4 Dec 2014, Ady wrote: >> >> > Perhaps there should be a new MENU-type directive, so to force the >> > screen to text mode (as opposed to leaving it in graphics mode for as >> > long as it can be)? Perhaps this could also be useful when exiting a >> > vesamenu to

On Thu, Dec 4, 2014 at 11:40 PM, Jeffrey Hutzelman <jhutz at cmu.edu> wrote: > On Thu, 2014-12-04 at 21:26 -0500, Gene Cumm wrote: > >> > Thanks, that works! How do I use that in the generic case? >> > The ?pxebsd.0? file can be called as? >> > >> > ? PXE loader >> > ? COMBOOT (16-bit) >> > ? DOS .COM >> > ? Multiboot