RusstopiaLabs
/
xs
mirror of https://gogs.blitter.com/RLabs/xs
1
0
Fork 0
Code Issues Releases Wiki Activity

Update 'README.md'

This commit is contained in:
Russtopia 2022-07-02 12:00:12 -07:00
parent 819b359306
commit 73eadf7534
1 changed files with 6 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
README.md
View File

@ -105,17 +105,15 @@ As of this time (Oct 2018) Kyber is one of the candidate algorithms submitted to
### Get source code
```
$ go get -u blitter.com/go/xs
$ cd $GOPATH/src/blitter.com/go/xs
$ go build ./... # install all dependent go pkgs
$ git clone https://gogs.blitter.com/RLabs/xs
```
### To build
```
$ cd $GOPATH/src/blitter.com/go/xs
$ make clean all
$ cd xs
$ make clean && make
```
### To install, uninstall, re-install
@ -146,6 +144,7 @@ The make system assumes installation in /usr/local/sbin (xsd, xspasswd) and /usr
```
$ sudo rc-config [start | restart | stop] xsd
# .. or sudo /etc/init.d/xsd [start | restart stop]
```
### To set accounts & passwords:
@ -214,7 +213,7 @@ NOTE: Renaming while copying (eg., 'cp /foo/bar/fileA ./fileB') is NOT supported
If the 'pv' pipeview utility is available (http://www.ivarch.com/programs/pv.shtml) file transfer progress and bandwidth control will be available (suppress the former with the -q option, set the latter with -L <bytes_per_second>).
Special care should be taken when doing client->server copies: since the tarpipe (should) always succeed at least sending data to the remote side, a destination with no write permission will not return a nonzero status and the client closes its end after sending all data, giving the server no opportunity to send an error code to the client.
Special care should be taken when doing client → server copies: since the tarpipe (should) always succeed at least sending data to the remote side, a destination with no write permission will not return a nonzero status and the client closes its end after sending all data, giving the server no opportunity to send an error code to the client.
It is recommended to test beforehand if the server-side destination is writable (and optionally if the destination already exists, if one does not want to clobber an existing path) by:
```
@ -226,7 +225,7 @@ Perhaps in future a more complex handshake will be devised to allow the client t
### Tunnels
Simple tunnels (client -> server, no reverse tunnels for now) are supported.
Simple tunnels (client → server, no reverse tunnels for now) are supported.
Syntax: xs -T=<tunspec>{,<tunspec>...}
.. where <tunspec> is <localport:remoteport>