FIles via SsH, or FIles via SHell, or something like that.
A protocol for file transfers over ssh (or the like) connections, providing FTP-like abilities to browse the remote file system, create directories, etc. while needing only /bin/sh and a few other standard POSIX features to be available on the server.
Apparently rather popular in the KDE community.
A format specification can be found at [1 ].
SEH I'm trying to do something fun related to this, and I'm trying to poach some of the shell commands in the above referenced link, but there's one that I just don't quite get what's goin on. To store the contents of a file that is to be read from stdin, the following shell command is suggested:
> /file/name; echo '### 001'; ( dd bs=4096 count=<size/4096>; dd bs=<size%4096> count=1 ) 2>/dev/null | ( cat > %s; cat > /dev/null ); echo '### 200' This command is for storing /file/name, which is exactly size bytes big. You probably think I went crazy. Well, I did not: that strange cat > /dev/null has purpose to discard any extra data which was not written to disk (due to for example out of space condition).
Now perhaps there is a typo and 'cat' was intended at the beginning of the line. Then apparently the dd commands are to check for overflow perhaps caused by disk failure, but the 'cat > %s' has me at sea.
Can anybody better at shell programming than me give a better explanation of just what's going on here?
Lars H: I suspect that %s should be replaced by the name of the file to store, but whether this is something that should be substituted before sending the command (like the <size/4096> and <size%4096> most likely are) or whether it employs some sh magic I cannot say. The > /file/name at the beginning of the line looks very strange too, so perhaps they're supposed to work together.
The dd commands are for reading some exact number of bytes from stdin, similar to
puts -nonewline [read stdin $size]
2005-11-08 VI The > filename at the beginning makes a zero size file. effectively truncating it to zero bytes if it already exists.
The dd commands are just trying to be efficient, first do as many 4096-byte blocks as you can, then do the remainder in one block. The > /dev/null is what takes care of disk errors. As LH says, the "%s" is supposed to be the same as /file/name and the expressions involving size can be precomputed.
Do let us know if you managed get something halfway done. I'd love to contribute, but can't really overcome inertia.