{ "content": [ { "type": "text", "text": "# ZSHZFTPSYS(1) (man)\n\n**Summary:** zshzftpsys - zftp function front-end\n\n## Section Outline\n\n- **NAME** (2 lines)\n- **DESCRIPTION** (19 lines)\n- **INSTALLATION** (18 lines)\n- **FUNCTIONS** (5 lines) — 12 subsections\n - Opening a connection (41 lines)\n - Directory management (1 lines)\n - zfcd - (49 lines)\n - Status commands (10 lines)\n - Retrieving files (40 lines)\n - Sending files (41 lines)\n - Closing the connection (1 lines)\n - zfclose (2 lines)\n - Session management (32 lines)\n - Bookmarks (28 lines)\n - Other functions (65 lines)\n - zffcache (3 lines)\n- **MISCELLANEOUS FEATURES** (1 lines) — 7 subsections\n - Configuration (14 lines)\n - progress (17 lines)\n - remote-glob (3 lines)\n - titlebar (15 lines)\n - Remote globbing (17 lines)\n - Automatic and temporary reopening (33 lines)\n - Completion (9 lines)\n\n## Full Content\n\n### NAME\n\nzshzftpsys - zftp function front-end\n\n### DESCRIPTION\n\nThis describes the set of shell functions supplied with the source distribution as an inter‐\nface to the zftp builtin command, allowing you to perform FTP operations from the shell com‐\nmand line or within functions or scripts. The interface is similar to a traditional FTP\nclient (e.g. the ftp command itself, see ftp(1)), but as it is entirely done within the shell\nall the familiar completion, editing and globbing features, and so on, are present, and\nmacros are particularly simple to write as they are just ordinary shell functions.\n\nThe prerequisite is that the zftp command, as described in zshmodules(1) , must be available\nin the version of zsh installed at your site. If the shell is configured to load new com‐\nmands at run time, it probably is: typing `zmodload zsh/zftp' will make sure (if that runs\nsilently, it has worked). If this is not the case, it is possible zftp was linked into the\nshell anyway: to test this, type `which zftp' and if zftp is available you will get the mes‐\nsage `zftp: shell built-in command'.\n\nCommands given directly with zftp builtin may be interspersed between the functions in this\nsuite; in a few cases, using zftp directly may cause some of the status information stored in\nshell parameters to become invalid. Note in particular the description of the variables\n$ZFTPTMOUT, $ZFTPPREFS and $ZFTPVERBOSE for zftp.\n\n### INSTALLATION\n\nYou should make sure all the functions from the Functions/Zftp directory of the source dis‐\ntribution are available; they all begin with the two letters `zf'. They may already have\nbeen installed on your system; otherwise, you will need to find them and copy them. The di‐\nrectory should appear as one of the elements of the $fpath array (this should already be the\ncase if they were installed), and at least the function zfinit should be autoloaded; it will\nautoload the rest. Finally, to initialize the use of the system you need to call the zfinit\nfunction. The following code in your .zshrc will arrange for this; assume the functions are\nstored in the directory ~/myfns:\n\nfpath=(~/myfns $fpath)\nautoload -U zfinit\nzfinit\n\nNote that zfinit assumes you are using the zmodload method to load the zftp command. If it\nis already built into the shell, change zfinit to zfinit -n. It is helpful (though not es‐\nsential) if the call to zfinit appears after any code to initialize the new completion sys‐\ntem, else unnecessary compctl commands will be given.\n\n### FUNCTIONS\n\nThe sequence of operations in performing a file transfer is essentially the same as that in a\nstandard FTP client. Note that, due to a quirk of the shell's getopts builtin, for those\nfunctions that handle options you must use `--' rather than `-' to ensure the remaining argu‐\nments are treated literally (a single `-' is treated as an argument).\n\n#### Opening a connection\n\nzfparams [ host [ user [ password ... ] ] ]\nSet or show the parameters for a future zfopen with no arguments. If no arguments are\ngiven, the current parameters are displayed (the password will be shown as a line of\nasterisks). If a host is given, and either the user or password is not, they will be\nprompted for; also, any parameter given as `?' will be prompted for, and if the `?' is\nfollowed by a string, that will be used as the prompt. As zfopen calls zfparams to\nstore the parameters, this usually need not be called directly.\n\nA single argument `-' will delete the stored parameters. This will also cause the\nmemory of the last directory (and so on) on the other host to be deleted.\n\nzfopen [ -1 ] [ host [ user [ password [ account ] ] ] ]\nIf host is present, open a connection to that host under username user with password\npassword (and, on the rare occasions when it is necessary, account account). If a\nnecessary parameter is missing or given as `?' it will be prompted for. If host is\nnot present, use a previously stored set of parameters.\n\nIf the command was successful, and the terminal is compatible with xterm or is\nsun-cmd, a summary will appear in the title bar, giving the local host:directory and\nthe remote host:directory; this is handled by the function zftpchpwd, described be‐\nlow.\n\nNormally, the host, user and password are internally recorded for later re-opening,\neither by a zfopen with no arguments, or automatically (see below). With the option\n`-1', no information is stored. Also, if an open command with arguments failed, the\nparameters will not be retained (and any previous parameters will also be deleted). A\nzfopen on its own, or a zfopen -1, never alters the stored parameters.\n\nBoth zfopen and zfanon (but not zfparams) understand URLs of the form\nftp://host/path... as meaning to connect to the host, then change directory to path\n(which must be a directory, not a file). The `ftp://' can be omitted; the trailing\n`/' is enough to trigger recognition of the path. Note prefixes other than `ftp:' are\nnot recognized, and that all characters after the first slash beyond host are signifi‐\ncant in path.\n\nzfanon [ -1 ] host\nOpen a connection host for anonymous FTP. The username used is `anonymous'. The\npassword (which will be reported the first time) is generated as user@host; this is\nthen stored in the shell parameter $EMAILADDR which can alternatively be set manually\nto a suitable string.\n\n#### Directory management\n\nzfcd [ dir ]\n\n#### zfcd -\n\nzfcd old new\nChange the current directory on the remote server: this is implemented to have many\nof the features of the shell builtin cd.\n\nIn the first form with dir present, change to the directory dir. The command `zfcd\n..' is treated specially, so is guaranteed to work on non-UNIX servers (note this is\nhandled internally by zftp). If dir is omitted, has the effect of `zfcd ~'.\n\nThe second form changes to the directory previously current.\n\nThe third form attempts to change the current directory by replacing the first occur‐\nrence of the string old with the string new in the current directory.\n\nNote that in this command, and indeed anywhere a remote filename is expected, the\nstring which on the local host corresponds to `~' is converted back to a `~' before\nbeing passed to the remote machine. This is convenient because of the way expansion\nis performed on the command line before zfcd receives a string. For example, suppose\nthe command is `zfcd ~/foo'. The shell will expand this to a full path such as `zfcd\n/home/user2/pws/foo'. At this stage, zfcd recognises the initial path as correspond‐\ning to `~' and will send the directory to the remote host as ~/foo, so that the `~'\nwill be expanded by the server to the correct remote host directory. Other named di‐\nrectories of the form `~name' are not treated in this fashion.\n\nzfhere Change directory on the remote server to the one corresponding to the current local\ndirectory, with special handling of `~' as in zfcd. For example, if the current local\ndirectory is ~/foo/bar, then zfhere performs the effect of `zfcd ~/foo/bar'.\n\nzfdir [ -rfd ] [ - ] [ dir-options ] [ dir ]\nProduce a long directory listing. The arguments dir-options and dir are passed di‐\nrectly to the server and their effect is implementation dependent, but specifying a\nparticular remote directory dir is usually possible. The output is passed through a\npager given by the environment variable $PAGER, or `more' if that is not set.\n\nThe directory is usually cached for re-use. In fact, two caches are maintained. One\nis for use when there is no dir-options or dir, i.e. a full listing of the current re‐\nmote directory; it is flushed when the current remote directory changes. The other is\nkept for repeated use of zfdir with the same arguments; for example, repeated use of\n`zfdir /pub/gnu' will only require the directory to be retrieved on the first call.\nAlternatively, this cache can be re-viewed with the -r option. As relative directo‐\nries will confuse zfdir, the -f option can be used to force the cache to be flushed\nbefore the directory is listed. The option -d will delete both caches without showing\na directory listing; it will also delete the cache of file names in the current remote\ndirectory, if any.\n\nzfls [ ls-options ] [ dir ]\nList files on the remote server. With no arguments, this will produce a simple list\nof file names for the current remote directory. Any arguments are passed directly to\nthe server. No pager and no caching is used.\n\n#### Status commands\n\nzftype [ type ]\nWith no arguments, show the type of data to be transferred, usually ASCII or binary.\nWith an argument, change the type: the types `A' or `ASCII' for ASCII data and `B' or\n`BINARY', `I' or `IMAGE' for binary data are understood case-insensitively.\n\nzfstat [ -v ]\nShow the status of the current or last connection, as well as the status of some of\nzftp's status variables. With the -v option, a more verbose listing is produced by\nquerying the server for its version of events, too.\n\n#### Retrieving files\n\nThe commands for retrieving files all take at least two options. -G suppresses remote file‐\nname expansion which would otherwise be performed (see below for a more detailed description\nof that). -t attempts to set the modification time of the local file to that of the remote\nfile: see the description of the function zfrtime below for more information.\n\nzfget [ -Gtc ] file1 ...\nRetrieve all the listed files file1 ... one at a time from the remote server. If a\nfile contains a `/', the full name is passed to the remote server, but the file is\nstored locally under the name given by the part after the final `/'. The option -c\n(cat) forces all files to be sent as a single stream to standard output; in this case\nthe -t option has no effect.\n\nzfuget [ -Gvst ] file1 ...\nAs zfget, but only retrieve files where the version on the remote server is newer (has\na later modification time), or where the local file does not exist. If the remote\nfile is older but the files have different sizes, or if the sizes are the same but the\nremote file is newer, the user will usually be queried. With the option -s, the com‐\nmand runs silently and will always retrieve the file in either of those two cases.\nWith the option -v, the command prints more information about the files while it is\nworking out whether or not to transfer them.\n\nzfcget [ -Gt ] file1 ...\nAs zfget, but if any of the local files exists, and is shorter than the corresponding\nremote file, the command assumes that it is the result of a partially completed trans‐\nfer and attempts to transfer the rest of the file. This is useful on a poor connec‐\ntion which keeps failing.\n\nNote that this requires a commonly implemented, but non-standard, version of the FTP\nprotocol, so is not guaranteed to work on all servers.\n\nzfgcp [ -Gt ] remote-file local-file\nzfgcp [ -Gt ] rfile1 ... ldir\nThis retrieves files from the remote server with arguments behaving similarly to the\ncp command.\n\nIn the first form, copy remote-file from the server to the local file local-file.\n\nIn the second form, copy all the remote files rfile1 ... into the local directory ldir\nretaining the same basenames. This assumes UNIX directory semantics.\n\n#### Sending files\n\nzfput [ -r ] file1 ...\nSend all the file1 ... given separately to the remote server. If a filename contains\na `/', the full filename is used locally to find the file, but only the basename is\nused for the remote file name.\n\nWith the option -r, if any of the files are directories they are sent recursively with\nall their subdirectories, including files beginning with `.'. This requires that the\nremote machine understand UNIX file semantics, since `/' is used as a directory sepa‐\nrator.\n\nzfuput [ -vs ] file1 ...\nAs zfput, but only send files which are newer than their remote equivalents, or if the\nremote file does not exist. The logic is the same as for zfuget, but reversed between\nlocal and remote files.\n\nzfcput file1 ...\nAs zfput, but if any remote file already exists and is shorter than the local equiva‐\nlent, assume it is the result of an incomplete transfer and send the rest of the file\nto append to the existing part. As the FTP append command is part of the standard\nset, this is in principle more likely to work than zfcget.\n\nzfpcp local-file remote-file\nzfpcp lfile1 ... rdir\nThis sends files to the remote server with arguments behaving similarly to the cp com‐\nmand.\n\nWith two arguments, copy local-file to the server as remote-file.\n\nWith more than two arguments, copy all the local files lfile1 ... into the existing\nremote directory rdir retaining the same basenames. This assumes UNIX directory se‐\nmantics.\n\nA problem arises if you attempt to use zfpcp lfile1 rdir, i.e. the second form of\ncopying but with two arguments, as the command has no simple way of knowing if rdir\ncorresponds to a directory or a filename. It attempts to resolve this in various\nways. First, if the rdir argument is `.' or `..' or ends in a slash, it is assumed to\nbe a directory. Secondly, if the operation of copying to a remote file in the first\nform failed, and the remote server sends back the expected failure code 553 and a re‐\nply including the string `Is a directory', then zfpcp will retry using the second\nform.\n\n#### Closing the connection\n\n#### zfclose\n\nClose the connection.\n\n#### Session management\n\nzfsession [ -lvod ] [ sessname ]\nAllows you to manage multiple FTP sessions at once. By default, connections take\nplace in a session called `default'; by giving the command `zfsession sessname' you\ncan change to a new or existing session with a name of your choice. The new session\nremembers its own connection, as well as associated shell parameters, and also the\nhost/user parameters set by zfparams. Hence you can have different sessions set up to\nconnect to different hosts, each remembering the appropriate host, user and password.\n\nWith no arguments, zfsession prints the name of the current session; with the option\n-l it lists all sessions which currently exist, and with the option -v it gives a ver‐\nbose list showing the host and directory for each session, where the current session\nis marked with an asterisk. With -o, it will switch to the most recent previous ses‐\nsion.\n\nWith -d, the given session (or else the current one) is removed; everything to do with\nit is completely forgotten. If it was the only session, a new session called `de‐‐\nfault' is created and made current. It is safest not to delete sessions while back‐\nground commands using zftp are active.\n\nzftransfer sess1:file1 sess2:file2\nTransfer files between two sessions; no local copy is made. The file is read from the\nsession sess1 as file1 and written to session sess2 as file file2; file1 and file2 may\nbe relative to the current directories of the session. Either sess1 or sess2 may be\nomitted (though the colon should be retained if there is a possibility of a colon ap‐\npearing in the file name) and defaults to the current session; file2 may be omitted or\nmay end with a slash, in which case the basename of file1 will be added. The sessions\nsess1 and sess2 must be distinct.\n\nThe operation is performed using pipes, so it is required that the connections still\nbe valid in a subshell, which is not the case under versions of some operating sys‐\ntems, presumably due to a system bug.\n\n#### Bookmarks\n\nThe two functions zfmark and zfgoto allow you to `bookmark' the present location (host, user\nand directory) of the current FTP connection for later use. The file to be used for storing\nand retrieving bookmarks is given by the parameter $ZFTPBMFILE; if not set when one of the\ntwo functions is called, it will be set to the file .zfbkmarks in the directory where your\nzsh startup files live (usually ~).\n\nzfmark [ bookmark ]\nIf given an argument, mark the current host, user and directory under the name book‐\nmark for later use by zfgoto. If there is no connection open, use the values for the\nlast connection immediately before it was closed; it is an error if there was none.\nAny existing bookmark under the same name will be silently replaced.\n\nIf not given an argument, list the existing bookmarks and the points to which they re‐\nfer in the form user@host:directory; this is the format in which they are stored, and\nthe file may be edited directly.\n\nzfgoto [ -n ] bookmark\nReturn to the location given by bookmark, as previously set by zfmark. If the loca‐\ntion has user `ftp' or `anonymous', open the connection with zfanon, so that no pass‐\nword is required. If the user and host parameters match those stored for the current\nsession, if any, those will be used, and again no password is required. Otherwise a\npassword will be prompted for.\n\nWith the option -n, the bookmark is taken to be a nickname stored by the ncftp program\nin its bookmark file, which is assumed to be ~/.ncftp/bookmarks. The function works\nidentically in other ways. Note that there is no mechanism for adding or modifying\nncftp bookmarks from the zftp functions.\n\n#### Other functions\n\nMostly, these functions will not be called directly (apart from zfinit), but are described\nhere for completeness. You may wish to alter zftpchpwd and zftpprogress, in particular.\n\nzfinit [ -n ]\nAs described above, this is used to initialize the zftp function system. The -n op‐\ntion should be used if the zftp command is already built into the shell.\n\nzfautocheck [ -dn ]\nThis function is called to implement automatic reopening behaviour, as described in\nmore detail below. The options must appear in the first argument; -n prevents the\ncommand from changing to the old directory, while -d prevents it from setting the\nvariable doclose, which it otherwise does as a flag for automatically closing the\nconnection after a transfer. The host and directory for the last session are stored\nin the variable $zflastsession, but the internal host/user/password parameters must\nalso be correctly set.\n\nzfcdmatch prefix suffix\nThis performs matching for completion of remote directory names. If the remote server\nis UNIX, it will attempt to persuade the server to list the remote directory with sub‐\ndirectories marked, which usually works but is not guaranteed. On other hosts it sim‐\nply calls zfgetmatch and hence completes all files, not just directories. On some\nsystems, directories may not even look like filenames.\n\nzfgetmatch prefix suffix\nThis performs matching for completion of remote filenames. It caches files for the\ncurrent directory (only) in the shell parameter $zftpfcache. It is in the form to be\ncalled by the -K option of compctl, but also works when called from a widget-style\ncompletion function with prefix and suffix set appropriately.\n\nzfrglob varname\nPerform remote globbing, as describes in more detail below. varname is the name of a\nvariable containing the pattern to be expanded; if there were any matches, the same\nvariable will be set to the expanded set of filenames on return.\n\nzfrtime lfile rfile [ time ]\nSet the local file lfile to have the same modification time as the remote file rfile,\nor the explicit time time in FTP format CCYYMMDDhhmmSS for the GMT timezone. This\nuses the shell's zsh/datetime module to perform the conversion from GMT to local time.\n\nzftpchpwd\nThis function is called every time a connection is opened, or closed, or the remote\ndirectory changes. This version alters the title bar of an xterm-compatible or\nsun-cmd terminal emulator to reflect the local and remote hostnames and current direc‐\ntories. It works best when combined with the function chpwd. In particular, a func‐\ntion of the form\n\nchpwd() {\nif [[ -n $ZFTPUSER ]]; then\nzftpchpwd\nelse\n# usual chpwd e.g put host:directory in title bar\nfi\n}\n\nfits in well.\n\nzftpprogress\nThis function shows the status of the transfer. It will not write anything unless the\noutput is going to a terminal; however, if you transfer files in the background, you\nshould turn off progress reports by hand using `zstyle ':zftp:*' progress none'. Note\nalso that if you alter it, any output must be to standard error, as standard output\nmay be a file being received. The form of the progress meter, or whether it is used\nat all, can be configured without altering the function, as described in the next sec‐\ntion.\n\n#### zffcache\n\nThis is used to implement caching of files in the current directory for each session\nseparately. It is used by zfgetmatch and zfrglob.\n\n### MISCELLANEOUS FEATURES\n\n#### Configuration\n\nVarious styles are available using the standard shell style mechanism, described in zshmod‐\nules(1). Briefly, the command `zstyle ':zftp:*' style value ...'. defines the style to have\nvalue value; more than one value may be given, although that is not useful in the cases de‐\nscribed here. These values will then be used throughout the zftp function system. For more\nprecise control, the first argument, which gives a context in which the style applies, can be\nmodified to include a particular function, as for example `:zftp:zfget': the style will then\nhave the given value only in the zfget function. Values for the same style in different con‐\ntexts may be set; the most specific function will be used, where strings are held to be more\nspecific than patterns, and longer patterns and shorter patterns. Note that only the top\nlevel function name, as called by the user, is used; calling of lower level functions is\ntransparent to the user. Hence modifications to the title bar in zftpchpwd use the contexts\n:zftp:zfopen, :zftp:zfcd, etc., depending where it was called from. The following styles are\nunderstood:\n\n#### progress\n\nControls the way that zftpprogress reports on the progress of a transfer. If empty,\nunset, or `none', no progress report is made; if `bar' a growing bar of inverse video\nis shown; if `percent' (or any other string, though this may change in future), the\npercentage of the file transferred is shown. The bar meter requires that the width of\nthe terminal be available via the $COLUMNS parameter (normally this is set automati‐\ncally). If the size of the file being transferred is not available, bar and percent\nmeters will simply show the number of bytes transferred so far.\n\nWhen zfinit is run, if this style is not defined for the context :zftp:*, it will be\nset to `bar'.\n\nupdate Specifies the minimum time interval between updates of the progress meter in seconds.\nNo update is made unless new data has been received, so the actual time interval is\nlimited only by $ZFTPTIMEOUT.\n\nAs described for progress, zfinit will force this to default to 1.\n\n#### remote-glob\n\nIf set to `1', `yes' or `true', filename generation (globbing) is performed on the re‐\nmote machine instead of by zsh itself; see below.\n\n#### titlebar\n\nIf set to `1', `yes' or `true', zftpchpwd will put the remote host and remote direc‐\ntory into the titlebar of terminal emulators such as xterm or sun-cmd that allow this.\n\nAs described for progress, zfinit will force this to default to 1.\n\nchpwd If set to `1' `yes' or `true', zftpchpwd will call the function chpwd when a connec‐\ntion is closed. This is useful if the remote host details were put into the terminal\ntitle bar by zftpchpwd and your usual chpwd also modifies the title bar.\n\nWhen zfinit is run, it will determine whether chpwd exists and if so it will set the\ndefault value for the style to 1 if none exists already.\n\nNote that there is also an associative array zfconfig which contains values used by the func‐\ntion system. This should not be modified or overwritten.\n\n#### Remote globbing\n\nThe commands for retrieving files usually perform filename generation (globbing) on their ar‐\nguments; this can be turned off by passing the option -G to each of the commands. Normally\nthis operates by retrieving a complete list of files for the directory in question, then\nmatching these locally against the pattern supplied. This has the advantage that the full\nrange of zsh patterns (respecting the setting of the option EXTENDEDGLOB) can be used. How‐\never, it means that the directory part of a filename will not be expanded and must be given\nexactly. If the remote server does not support the UNIX directory semantics, directory han‐\ndling is problematic and it is recommended that globbing only be used within the current di‐\nrectory. The list of files in the current directory, if retrieved, will be cached, so that\nsubsequent globs in the same directory without an intervening zfcd are much faster.\n\nIf the remote-glob style (see above) is set, globbing is instead performed on the remote\nhost: the server is asked for a list of matching files. This is highly dependent on how the\nserver is implemented, though typically UNIX servers will provide support for basic glob pat‐\nterns. This may in some cases be faster, as it avoids retrieving the entire list of direc‐\ntory contents.\n\n#### Automatic and temporary reopening\n\nAs described for the zfopen command, a subsequent zfopen with no parameters will reopen the\nconnection to the last host (this includes connections made with the zfanon command). Opened\nin this fashion, the connection starts in the default remote directory and will remain open\nuntil explicitly closed.\n\nAutomatic re-opening is also available. If a connection is not currently open and a command\nrequiring a connection is given, the last connection is implicitly reopened. In this case\nthe directory which was current when the connection was closed again becomes the current di‐\nrectory (unless, of course, the command given changes it). Automatic reopening will also\ntake place if the connection was close by the remote server for whatever reason (e.g. a time‐\nout). It is not available if the -1 option to zfopen or zfanon was used.\n\nFurthermore, if the command issued is a file transfer, the connection will be closed after\nthe transfer is finished, hence providing a one-shot mode for transfers. This does not apply\nto directory changing or listing commands; for example a zfdir may reopen a connection but\nwill leave it open. Also, automatic closure will only ever happen in the same command as au‐\ntomatic opening, i.e a zfdir directly followed by a zfget will never close the connection au‐\ntomatically.\n\nInformation about the previous connection is given by the zfstat function. So, for example,\nif that reports:\n\nSession: default\nNot connected.\nLast session: ftp.bar.com:/pub/textfiles\n\nthen the command zfget file.txt will attempt to reopen a connection to ftp.bar.com, retrieve\nthe file /pub/textfiles/file.txt, and immediately close the connection again. On the other\nhand, zfcd .. will open the connection in the directory /pub and leave it open.\n\nNote that all the above is local to each session; if you return to a previous session, the\nconnection for that session is the one which will be reopened.\n\n#### Completion\n\nCompletion of local and remote files, directories, sessions and bookmarks is supported. The\nolder, compctl-style completion is defined when zfinit is called; support for the new wid‐\nget-based completion system is provided in the function Completion/Zsh/Command/zftp, which\nshould be installed with the other functions of the completion system and hence should auto‐\nmatically be available.\n\n\n\nzsh 5.8.1 February 12, 2022 ZSHZFTPSYS(1)\n\n" } ], "structuredContent": { "command": "ZSHZFTPSYS", "section": "1", "mode": "man", "summary": "zshzftpsys - zftp function front-end", "synopsis": null, "tldr_summary": null, "tldr_examples": [], "tldr_source": null, "flags": [], "examples": [], "see_also": [], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "DESCRIPTION", "lines": 19, "subsections": [] }, { "name": "INSTALLATION", "lines": 18, "subsections": [] }, { "name": "FUNCTIONS", "lines": 5, "subsections": [ { "name": "Opening a connection", "lines": 41 }, { "name": "Directory management", "lines": 1 }, { "name": "zfcd -", "lines": 49 }, { "name": "Status commands", "lines": 10 }, { "name": "Retrieving files", "lines": 40 }, { "name": "Sending files", "lines": 41 }, { "name": "Closing the connection", "lines": 1 }, { "name": "zfclose", "lines": 2 }, { "name": "Session management", "lines": 32 }, { "name": "Bookmarks", "lines": 28 }, { "name": "Other functions", "lines": 65 }, { "name": "zffcache", "lines": 3 } ] }, { "name": "MISCELLANEOUS FEATURES", "lines": 1, "subsections": [ { "name": "Configuration", "lines": 14 }, { "name": "progress", "lines": 17 }, { "name": "remote-glob", "lines": 3 }, { "name": "titlebar", "lines": 15 }, { "name": "Remote globbing", "lines": 17 }, { "name": "Automatic and temporary reopening", "lines": 33 }, { "name": "Completion", "lines": 9 } ] } ] } }