Re: scp(1) changes in snaps
"Theo de Raadt": > 2) With very long names, it truncates the end of the path. This is less useful > information. Imagine a copy operation with multiple files being transferred, > one of them is huge and surprisingly long, but you cannot identify which one > because all the truncated long paths are the same. > > 3) (old) scp and rsync show the path only component only. Oh, I hadn't even realized that this affects the way _all_ source file paths are displayed, whether remote or local, whether originally specified with absolute or relative path. Path width is limited to 44 characters in a normal 80-char terminal. $ echo -n /usr/ports/distfiles/ |wc 0 1 21 $ echo -n /usr/ports/logs/amd64/paths/ |wc 0 1 28 > So I think the path-component-only scheme is better, and this should > change. Yes, please. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: scp(1) changes in snaps
Damien Miller wrote: > On Fri, 6 Aug 2021, Christian Weisgerber wrote: > > > Damien Miller: > > > > > Just a head-up: snaps currently contain a set of changes[1] to > > > make scp(1) use the SFTP protocol by default. > > > > > Please report any incompatibilities or bugs that you encounter here > > > (tech@), to bugs@ or to openssh@. > > > > An obvious cosmetic difference is that relative paths are prefixed > > with the home directory of the remote source in the progress bar: > > > > $ scp lorvorc:foo /dev/null > > /home/naddy/foo 100% 4099 1.6MB/s 00:00 > > > > $ scp -O lorvorc:foo /dev/null > > foo 100% 4099 3.7MB/s 00:00 > > > > > > I don't know if we care. > > Yeah, I'm inclined to leave the full paths unless there's a good argument > for truncating them. 1) Are there circumstances where the remote homedir expansion is slightly secret? 2) With very long names, it truncates the end of the path. This is less useful information. Imagine a copy operation with multiple files being transferred, one of them is huge and surprisingly long, but you cannot identify which one because all the truncated long paths are the same. 3) (old) scp and rsync show the path only component only. So I think the path-component-only scheme is better, and this should change.
Re: scp(1) changes in snaps
On Fri, 6 Aug 2021, Christian Weisgerber wrote: > Damien Miller: > > > Just a head-up: snaps currently contain a set of changes[1] to > > make scp(1) use the SFTP protocol by default. > > > Please report any incompatibilities or bugs that you encounter here > > (tech@), to bugs@ or to openssh@. > > An obvious cosmetic difference is that relative paths are prefixed > with the home directory of the remote source in the progress bar: > > $ scp lorvorc:foo /dev/null > /home/naddy/foo 100% 4099 1.6MB/s 00:00 > > $ scp -O lorvorc:foo /dev/null > foo 100% 4099 3.7MB/s 00:00 > > > I don't know if we care. Yeah, I'm inclined to leave the full paths unless there's a good argument for truncating them. -d
Re: scp(1) changes in snaps
Damien Miller: > Just a head-up: snaps currently contain a set of changes[1] to > make scp(1) use the SFTP protocol by default. > Please report any incompatibilities or bugs that you encounter here > (tech@), to bugs@ or to openssh@. An obvious cosmetic difference is that relative paths are prefixed with the home directory of the remote source in the progress bar: $ scp lorvorc:foo /dev/null /home/naddy/foo 100% 4099 1.6MB/s 00:00 $ scp -O lorvorc:foo /dev/null foo 100% 4099 3.7MB/s 00:00 I don't know if we care. -- Christian "naddy" Weisgerber na...@mips.inka.de
scp(1) changes in snaps
Hi, Just a head-up: snaps currently contain a set of changes[1] to make scp(1) use the SFTP protocol by default. This has a number of advantages, mostly relating to the improved security that comes from avoiding the use of a protocol that shambled out of the 1980s (SCP/RCP). A certain amount in incompatibility is to be expected: the SCP/RCP protocol implicitly uses the remote shell for glob expansion, and this can make quoting/escpaing problematic as it gets expanded twice, by both the local and remote shells. SFTP-based scp(1) avoids this and functions a lot more like what you'd typically expect. Given this, I consider this an improvement and so I'm leaning towards not trying to make the new code bug-compatible with SCP/RCP quoting. Note that the code supporting scp -3 over SFTP is very new and not very well-tested. So if you are a user of this feature then please give it a try. Please report any incompatibilities or bugs that you encounter here (tech@), to bugs@ or to openssh@. Thanks, Damien [1] https://github.com/djmdjm/openssh-wip/pull/7
