GETUNIX(1) UNIX Programmer's Manual GETUNIX(1) NAME cp11, cpv, cpu; ls11, lsv, lsu - read UNIX filesystems SYNOPSIS cp? [options] sourcefile [targetfile] ls? [options] directory DESCRIPTION C_p_? retrieves the named s_o_u_r_c_e_f_i_l_e_ from a UNIX file system. If a t_a_r_g_e_t_f_i_l_e_ is specified, the copy is placed there; oth- erwise the contents of the file are written to standard out- put. 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. Nor- mally, just filenames are listed; if the -l flag is given, more information (protection, modes) is printed. Other options recognized by both c_p_? and l_s_?: -d device Filesystem resides on the named d_e_v_i_c_e_ (or file), rather than the default. -v Filesystem is a VAX (32V) filesystem. -7 Filesystem is a version 7 filesystem. -6 Filesystem is a version 6 filesystem. -s Silent mode; error messages are suppressed. FILES /dev/v* VAX filesystems /dev/v7* V7 filesystems /dev/v6* V6 filesystems /bin/sort SEE ALSO ls(1) DIAGNOSTICS 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 out- put file are created as allocated blocks filled with zeros. HEP INFO Written at HEP by Rob Pike. Modified by Mark Bartelt. Printed 6/16/82 HEP 1 GETUNIX(1) UNIX Programmer's Manual GETUNIX(1) 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, -7 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 -v. 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 com- mands 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, -v and -7, respectively. File protection modes are checked to ensure that the person running the program actually has appropriate access permis- sion. 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. Fortunately, 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_k_s that aren't whole- block multiples. The VMS version of l_s_? does not produce sorted output. Printed 6/16/82 HEP 2