GETUNIX(1) GETUNIX(1) NNAAMMEE cp11, cpv, cpu; ls11, lsv, lsu - read UNIX filesystems SSYYNNOOPPSSIISS ccpp? [options] sourcefile [targetfile] llss? [options] directory DDEESSCCRRIIPPTTIIOONN _C_p? retrieves the named _s_o_u_r_c_e_f_i_l_e from a UNIX file sys- tem. If a _t_a_r_g_e_t_f_i_l_e is specified, the copy is placed there; otherwise the contents of the file are written to standard output. If the _t_a_r_g_e_t_f_i_l_e named is a directory, the file is copied there with the same basename as the original. _L_s? is similar to _c_p? (in fact, it is merely a link to it), but lists the contents of the directory _s_o_u_r_c_e_f_i_l_e; if the file is not a directory, it is listed by itself. Normally, just filenames are listed; if the --ll flag is given, more information (protection, modes) is printed. Other options recognized by both _c_p_? and _l_s_?: --dd device Filesystem resides on the named _d_e_v_i_c_e (or file), rather than the default. --vv Filesystem is a VAX (32V) filesystem. --77 Filesystem is a version 7 filesystem. --66 Filesystem is a version 6 filesystem. --ss Silent mode; error messages are suppressed. FFIILLEESS /dev/v* VAX filesystems /dev/v7* V7 filesystems /dev/v6* V6 filesystems /bin/sort SSEEEE AALLSSOO ls(1) DDIIAAGGNNOOSSTTIICCSS Most are self-explanatory. "File has hole(s)" means that the file contains an unallo- cated block. This usually indicates something weird with the file, but may be a normal condition. Holes in the output file are created as allocated blocks filled with zeros. HEP 1 GETUNIX(1) GETUNIX(1) HHEEPP IINNFFOO Written at HEP by Rob Pike. Modified by Mark Bartelt. Further hacked by Norman Wilson. Hacked still more by Mark Bartelt. On the UNIX VAX, the program is named _c_p_1_1 and _l_s_1_1, and is used to fetch files from the PDP-11/45 RJE system. Since the RJE system is now running a V7 system, --77 is the default. On the 11/45, the program is named _c_p_v and _l_s_v, and is used to fetch files from the VAX. The default is --vv. Now also runs under VMS (ported via EUNICE), where the disks containing UNIX filesystems are mounted foreign with names $UNIX0, $UNIX1, and so forth. The following foreign commands are defined: cpu*nix :== $sys$sysdisk:[bin]getunix cpunix lsu*nix :== $sys$sysdisk:[bin]getunix lsunix cpv*ax :== $sys$sysdisk:[bin]getunix cpvax lsv*ax :== $sys$sysdisk:[bin]getunix lsvax cp11 :== $sys$sysdisk:[bin]getunix cp11 ls11 :== $sys$sysdisk:[bin]getunix ls11 On the VMS VAX, _c_p_u_/_l_s_u (and _c_p_v_/_l_s_v) are used to fetch files from the UNIX VAX, _c_p_1_1_/_l_s_1_1 to fetch files from the 11/45. Defaults are, obviously, --vv and --77, respectively. File protection modes are checked to ensure that the per- son running the program actually has appropriate access permission. When running under VMS, the access test is modified somewhat: Since there is no convenient way to map UNIX UIDs and VMS UIC member numbers onto each other, only group and world access are checked. Furthermore, a group match is defined to exist if the decimal representation of the UNIX GID is the same as the octal representation of the VMS UIC group number. This is done to make things easier for people who set up accounts: If a group on the VMS machine is, say, 123 (octal), that same group must be 123 (decimal) on the UNIX machines, and vice-versa. For- tunately, that's the way things are set up here. Note that files which are readable only to owner cannot be copied to the VMS system. The UNIX version needs to read ``cooked'' devices rather than ``raw'' ones, since it does _l_s_e_e_ks that aren't whole- block multiples. The VMS version of _l_s? does not produce sorted output. HEP 2