similar to: -e escape rule

On 2016-10-20 10:24, Samuel Williams wrote: > Hello, > > I'm using Ruby's Shellwords module, which generates a string from an > array, suitable for shell evaluation. > > Ruby's implementation prefers escaping whitespace with a backslash > rather than quotes. However, this appears to cause some kind of issue > in Rsync when it computes argv from -e option. The

Hi Dave, thanks for point that out. I didn't realise there was a detailed explanation of that field in the man page, I only saw the summary. Yes, that clearly explains how it's supposed to work. On 21 October 2016 at 01:46, Dave Howorth <dhoworth at mrc-lmb.cam.ac.uk> wrote: > On 2016-10-20 10:24, Samuel Williams wrote: >> >> Hello, >> >> I'm using

> Yeah, it only does space-splitting and that's all it will ever do. It still looks to me like there is a bug in the original escaping, since any command receiving that string is receiving a backslash that is not supposed to be there. It should only be escaping the string enough to get it to rsync, not trying to guess what rsync is going to do with it after it gets it. I'm not

> The point is that the original escaping DOUBLE escapes an equals sign: > foo\\\=bar > It shouldn't, there's no reason to. If you paste into your command line: rsync -e ssh\ -l\ backup\ -i\ /etc/synco/id_rsa\ -o\ ConnectTimeout\\\=60\ -o\ BatchMode\\\=yes The list of arguments would be (i.e. the values in ARGV): ['rsync', '-e', 'ssh -l backup -i

https://bugzilla.samba.org/show_bug.cgi?id=5701 Summary: deadlock on local rsyncing, bisected to commit f303b749f2843433c9acd8218a4b9096d0d1bb8d Product: rsync Version: 3.1.0 Platform: All OS/Version: Linux Status: NEW Severity: major Priority: P3 Component: core AssignedTo:

https://bugzilla.samba.org/show_bug.cgi?id=8308 Summary: rsync: exclude.c:532: change_local_filter_dir: Assertion `dir_depth < 4096/2+1' failed Product: rsync Version: 3.0.8 Platform: x86 OS/Version: Linux Status: NEW Severity: major Priority: P5 Component: core

Hi: I'm in the middle of recoverying from a tactical error copying around an Mac OS X 10.10.5 Time Machine backup (turns out Apple's instructions aren't great...), and I had rsync running for the past 6 hours repairing permissions/acls on 1.5 TB of data (not copying the data), and then it just died in the middle with: .L....og.... 2015-03-11-094807/platinum-bar2/usr/local/mysql

> assuming that a shell is being used is invalid I never made this assumption. I looked directly at the source code and I stated that "I feel that this function should also handle backslash escapes." I think the assumption that splitting the command works the same way as (all?) major shells, is not inappropriate given the circumstances, and it seems like you agree. > but

Hi all, I have somewhat a strange problem that I could not figure out, maybe someone here can lelp. I have a script that uses scp to distribute files to many servers, I use '-o BatchMode=yes -o ConnectTimeout=2 options so the scp will not get stuck if something is wrong with the remote host. If the remote host is down (non-pingable) or sshd is down the timeout option works and the scp

Has anyone any idea why this wont work? Its in a script and im passing -e "${SSH}" to the Rsync command where :- SSH="$(/usr/bin/which ssh) -o ConnectTimeout=15 -o BatchMode=yes -n" The below is output from set -x for my script. Below that is the error from errorlog /usr/bin/rsync -PavRz --delete --delete-excluded --copy-unsafe-links --numeric-ids -e /usr/bin/ssh -o

I ran the following command to create a reverse tunnel from another server back to my local host ssh -4xnT -o PreferredAuthentications=publickey -o ConnectTimeout=10 -o BatchMode=yes -f \ -o ExitOnForwardFailure=yes -N -R myTargetHost:2525:myLocalHost:25 myUser at myTargetHost and on machine=myTargetHost, the port 2525 was already being utilized, so it gave me this error and exited: ? ?? Error:

Checking up on this change: On Wed, 29 Mar 2023 at 19:38, Ed Maste <emaste at freefall.freebsd.org> wrote: > > From: Ed Maste <emaste at FreeBSD.org> > > By convention settings in ssh_config are shown with a commented out > default. > > Fixes: 6cb52d5bf771 ("upstream: make CheckHostIP default to 'no'...") > --- > ssh_config | 2 +- > 1

Is there a way to omit the text printed out by issue(5) on some systemes? Like what --no-motd does for motd-texts.

If I have a "simple" variable value, this works fine: capmon@peter:~> puppet -e ''$v="xyz" exec { f: command => "/bin/echo v is $v", logoutput => true }'' notice: /Stage[main]//Exec[f]/returns: v is xyz notice: /Stage[main]//Exec[f]/returns: executed successfully But how do I escape "bad" values of $v? Painful examples like the

Hello OpenSSH folks, This was a really minor knit, but I noted while I was developing a pexpect module for ssh that setting ConnectTimeout to 0 in the options to ssh sets the login timeout to infinite time. I was wondering whether or not this was a documentation bug and/or potential clarification that could to be made, or if this was a software bug that needs to be fixed. I don't see

On Sat, Oct 29, 2016 at 5:36 AM, Samuel Williams < space.ship.traveller at gmail.com> wrote: > The command > > ssh -l backup -i /etc/synco/id_rsa -o ConnectTimeout\=60 -o BatchMode\=yes > > Is a correct and valid shell command. > It is, but there is no shell involved, and assuming that a shell is being used is invalid. Adding backslash escaping now could potentially screw

Hi all, I'm really struggling with getting Kerberos authentication to work between a FreeBSD host and a Linux host. I'm using the latest 6- STABLE code on the FreeBSD box, I've got forwardable Kerberos tokens (verified with "klist -f") and Kerberos and ssh are working fine in all other ways, but I can't get the Linux box to accept the Kerberos ticket as

Fix bug ConnectTimeout=N only works on the first ConnectionAttempts https://bugzilla.mindrot.org/show_bug.cgi?id=2918 --- sshconnect.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sshconnect.c b/sshconnect.c index 4862da5e..b837a83a 100644 --- a/sshconnect.c +++ b/sshconnect.c @@ -454,11 +454,12 @@ waitrfd(int fd, int *timeoutp) { struct pollfd pfd; struct timeval

Hi, usualy, in the unix world, while processing command line options, unix programs keep the last option value, overriding config file options or previous command line ones, unfortunately, ssh only keep the first option processed. ex. : ssh -o BatchMode=no -o BatchMode=yes host cmd arg... the unix common expected behaviour is to have BatchMode = true, while ssh says BatchMode = false. how

On Fri, Oct 28, 2016 at 5:39 AM, Samuel Williams < space.ship.traveller at gmail.com> wrote: > Rsync passed the backslashes through without dealing with them. > Yeah, it only does space-splitting and that's all it will ever do. It still looks to me like there is a bug in the original escaping, since any command receiving that string is receiving a backslash that is not supposed