Oh, right, I didn’t notice that because the line about theTried that, but didn't work: "/-x" jumps to the line that has "--xattrs, -X".
-xoption is just a few lines below that. I guess it depends on the window size and less options (I have
LESS="-RMeiqa -#8 -j.5 -z-4").
I wonder, too. It works for me. Maybe you had a typo?Searching for "/filesystem" interestingly doesn't find anything (I wonder why not).
Well … Arguably, someone who uses shell commands (and especially when writing scripts) should know how shells work. If he doesn’t, he should either learn, or use a graphical front-end that hides the technical details. Yeah, I know, in reality it’s not that easy, unfortunately.For me, who knows how shells work, that's reasonably easy. Typically I get it on the second try. Again, for a simple tool like scp, it should work on the first try: if the command works for cp, it should work for scp, just with "host:" or "user@host:" prefixed.
Saying that scp should be just as easy to use as cp is a little bit too simple, I think. For example, you have to take care if a file name contains a colon, because the colon character is special to the scp command. You also need to know certain details about the remote system, for example how file names are interpreted on the remote side, especially when it’s not a UFS/FFS compatible filesystem.
It’s not that easy, unfortunately.Absolutely. This just has to be disallowed scp.
The problem is that scp lets the remote shell parse the whole argument. This has several implications: it parses quoting, performs white-space splitting, parameter expansion (some people might have legitimate use for this!), command substitution, filename expansion (a.k.a. globbing), and so on. So the question is, which of these things do we want to disallow. And the next question is how to disallow them. Should we pre-parse the arguments, so we remove (or quote?) unwanted things, before passing the result to the shell? Or should we bypass the shell completely and implement our own parsing with quoting, white-space splitting and other things that may be used legitimately and that we need for compatibility? This is very non-trivial.
Another problem is that the remote shell might have a different feature set from the local shell. For example, the character sequence
[[is not special for FreeBSD’s /bin/sh (the command
echo [[just prints “
[[”). However, it has a special meaning for other shells like zsh and bash (zsh will print “
bad pattern: [[”). Solaris’ /bin/sh doesn’t know the
$(...)syntax for command substitution. And bash performs white-space splitting on the result of parameter expansion by default, while zsh does not. These are just a few examples, there are many more. So, it depends on the remote shell which things need to be quoted. And even the quoting syntax itself can have subtle differences between shells. It’s really a can of worms.
That is why the OpenSSH developers decided not to try to “fix” scp, but declare it obsolete. It’s better to create a new tool that behaves similarly to scp, but doesn’t try to be compatible with it. In particular, it should not parse arguments on the remote side in any way.
Well, it’s clear for a human that the user didn’t intend that, but it’s not clear to the shell or to the rm command. The rm command doesn’t see what the user typed, it only sees what the shell passes to it. And most shells don’t have any knowledge about the rm command and what theThe classic joke is a person who create a file named "-R", and then wonders why "rm -f *" recursively deletes subdirectories too, even though the user clearly didn't intend that.
-foption of that command does, because it’s usually an external command, not a shell-builtin.
By the way, the zsh fixes this particular problem: It recognizes the rm command (even when it’s used via an alias) together with a “dangerous” pattern like
*. In this case it prints “sure you want to delete all <n> files in <directory>? (waiting ten seconds)”, then waits 10 seconds (you can abort with Ctrl-C, of course), flushes all input received within those ten seconds, and then waits for the user to type “y”. Of course, this behavior can be disabled if you don’t want it. Personally I keep it enabled, just in case. When I’m sure that I know what I’m doing, I press <Tab> on the pattern to expand it before pressing <Enter>, avoiding the waiting time and confirmation.
Exactly.Agree. Something like scp is needed, just deleting the current one creates a hardship. But the new one has to be better, and that will make it different, so it also needs a different name.
By the way, a simple replacement for scp could be implemented as a shell script. It would just have to collect the source files and/or directories into a tar archive (or cpio, or whatever), transfer the archive through stdout/stdin of an ssh connection and extract the archive in the destination directory on the target machine. In fact I have already done things like that in shell scripts, when scp was unsuitable for various reasons. This is an excerpt from one of my scripts that copies a certain directory tree (slightly modified and simplified):
cd $SOURCEDIR find . -depth -not -name '*~' -and -not -iname '*.bak' -print0 | cpio -o -0 | ssh $TARGET "cd \"$DESTDIR\" && cpio -idum"