Hi I think I found a small filename handling issue in scp: evaldo at winston:~$ scp evaldo at 127.0.0.1:test-\`whoami\`-test . Password: scp: test-evaldo-test: No such file or directory evaldo at winston:~$ scp evaldo at 127.0.0.1:test-\`echo\ foo\`-test . Password: scp: test-foo-test: No such file or directory evaldo at winston:~$ evaldo at winston:~$ ssh -V OpenSSH_3.9 NetBSD_Secure_Shell-20050213, OpenSSL 0.9.7d 17 Mar 2004 (yeah, I know I am going to be larted for using a non-pure ssh, but I tried it with the portable openssh under linux and netbsd too, and the same thing happened) Evaldo Gardenali Please CC me any replies, as I am not subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3965 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050724/3ddb1839/attachment.bin
Evaldo Gardenali wrote:> I think I found a small filename handling issue in scp: > > evaldo at winston:~$ scp evaldo at 127.0.0.1:test-\`whoami\`-test . > Password: > scp: test-evaldo-test: No such file or directory > evaldo at winston:~$ scp evaldo at 127.0.0.1:test-\`echo\ foo\`-test . > Password: > scp: test-foo-test: No such file or directory > evaldo at winston:~$I don't follow, what did you expect? Do the files "test-evaldo-test" and "test-foo-test" exist? It behaves consistly with what I'd expect (remember: the shell expansion occurs twice: once by the client's shell and once by the server's). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
Evaldo Gardenali wrote:> I think I found a small filename handling issue in scp: > [...concerning special shell characters not being escaped and files > that contain those characters causing trouble...]I suggest you use rsync with ssh to copy files in this instance. The remote shell only invokes the other half of the rsync program. And after that the shell is not involved in the transfer. Bob