gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/26/88)
In article <11470@brl-adm.ARPA> iunix1@almsa-1.arpa (Will Martin) writes: >Since "ls" has a "-i" option that will show you the inode # of the file, >I have always wondered why that other commands such as "rm" do not also >have such an option, so that you could refer to a file by its inode >number instead of by its name. You'll probably be embarrassed by the answer: "rm" removes a link, not an inode. By the way, you can use rm pattern where "pattern" is some shell R.E. that matches just the link name you're after. Another, more usual approach is rm -ri .
lm@arizona.edu (Larry McVoy) (01/28/88)
In article <11470@brl-adm.ARPA> iunix1@almsa-1.arpa (Will Martin) writes: >around the weird file name with wildcards, we often end up just ignoring >it and leaving it be, because, when these appear in a regular production >directory, either that of an individual or a system-level one, it is often >not feasible to do the usual kinds of drastic measures, such as moving all try $ rm -i * -- Larry McVoy lm@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm Use the force - read the source.
rwelsh@cct.bbn.com (Robert J. Welsh) (01/29/88)
Will,
If you want to get rid of files that have control characters etc in their
name, this should work:
1) ls -i to get the inode number
2) set `ls -i | grep <desired Inode#>`; rm $2
If you just want to rename the file so you can get at it, replace the
rm $2
with
mv $2 <newname>
or any other command, using $2 as the source file name.
This will work in the standard shell, 'sh', and derivatives thereof.
Regards,
Rob Welshdavidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (01/29/88)
In article <831@dolqci.UUCP> stein@dolqci.UUCP (Mike Stein) writes: on accessing file by inode... | Yes! You can do anything you want via | | find <path> -inum <inode> -exec <command> \; | | In the <command> you refer to the file as '{}'. Thus, if you have a | file in the current directory with an insane name (but you know its | inode number is '1234') and you want to rename it 'foo', you would type: | | find . -inum 1234 -exec mv {} foo \; You would be well advised to use "{}" for the filename, too. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
jjw@celerity.UUCP (Jim ) (01/29/88)
In article <11470@brl-adm.ARPA> iunix1@almsa-1.arpa (Will Martin) asks: >Is there some trick I just don't know that would allow me to refer to a >file by its inode # in performing otherwise-ordinary UNIX commands, >like "cp" or "rm"? Or have people written special commands that will do >this sort of thing? And in article <831@dolqci.UUCP> stein@dolqci.UUCP (Mike Stein) responds: > Yes! You can do anything you want via > > find <path> -inum <inode> -exec <command> \; *********************************************************************** WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING *********************************************************************** The find will traverse file mount points so you may locate files in file systems other than the one you are interested in. Be especially careful with using "rm -f" as the command. It is possible to use "-ok" instead of "-exec" which will ask if you want the operation to be performed when the file(s) are located. However the "find" can take a long time on large file systems. -- J. J. Whelan
ok@quintus.UUCP (Richard A. O'Keefe) (01/29/88)
[The task is to delete a file whose name contains strange characters.] [The original poster thought that using Inode numbers was a good idea] [but couldn't quite see what to do next. ] In article <11525@brl-adm.ARPA>, rwelsh@cct.bbn.com (Robert J. Welsh) writes: > If you want to get rid of files that have control characters etc in their > name, this should work: > 1) ls -i to get the inode number > 2) set `ls -i | grep <desired Inode#>`; rm $2 > This will work in the standard shell, 'sh', and derivatives thereof. I'm afraid it WON'T work if the file name contains any characters in IFS. (In particular, spaces and tabs.) Do the following: $ mkdir scratch $ cd scratch $ cat </dev/null >"foo baz" $ ls -i The output I got was 20545 foo baz $ set `ls -i | grep 20545` $ echo $2 The output I got was foo A subsequence $ rm $2 therefore tries to delete a file called "foo". You have similar problems using wild-cards: $ rm fo* reports the non-existence of "foo" and "baz". find(1) seems to work: $ find . -inum ${DesiredInodeNumber} -exec rm {} \; Of course, in this case $ rm 'foo baz' also works. With a BSD terminal driver, you can type in any characters at all, so you don't need special tools or hacks. For example, if the file you want is ^A^B^Cfoo^Ibaz^D (^X means control-X), and if the literal-next character is ^V, just do $ rm '^V^A^V^B^V^Cfoo^Ibaz^V^D' The ultimate method, of course, is to write a C program, calling unlink().
dmt@ptsfa.UUCP (Dave Turner) (01/30/88)
In article <602@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >[The task is to delete a file whose name contains strange characters.] >[The original poster thought that using Inode numbers was a good idea] >[but couldn't quite see what to do next. ] > >In article <11525@brl-adm.ARPA>, rwelsh@cct.bbn.com (Robert J. Welsh) writes: >> If you want to get rid of files that have control characters etc in their On System V Rel 2.1 (and earlier) I've had good luck with the following: od -c . # to determine the "real" characters in the filename Then some combination of: rm 'filename in quotes' Sometimes it is necessary to ESCAPE certain characters in the filename. This almost always works. -- Dave Turner 415/542-1299 {ihnp4,lll-crg,qantel,pyramid}!ptsfa!dmt
schwartz@gondor.cs.psu.edu (Scott E. Schwartz) (01/31/88)
In article <530@celerity.UUCP> jjw@celerity.UUCP (Jim (JJ) Whelan) writes: >> find <path> -inum <inode> -exec <command> \; >The find will traverse file mount points so you may locate files in file >systems other than the one you are interested in. Be especially careful >with using "rm -f" as the command. If you are playing with "-inum" it is probably a good idea to use "-xdev" also, if you want to prevent find from traversing other filesystems. Do all versions of find support -xdev? 4.3BSD and SunOS3.4 find have it, at any rate. -- Scott Schwartz schwartz@gondor.cs.psu.edu
cutter@cutsys.UUCP (Bernie Hoffstadt ) (02/01/88)
In article <11470@brl-adm.ARPA> iunix1@almsa-1.arpa (Will Martin) writes: >Is there some trick I just don't know that would allow me to refer to a >file by its inode # in performing otherwise-ordinary UNIX commands, >like "cp" or "rm"? Or have people written special commands that will do >this sort of thing? I was SURE there was an option to find for matching a file with a certain inode number, but my runtime manual for Microport SystemV v2.2 didn't show it. Checking the manual for our old Xenix 1.00.02 system (Version 7), I found that the option is called -inum, and also works on my Microport system. Will could cd to the offending directory which has this output from ls -li 345 -rw-rw-r-- 1 iunix1 local 44 Jan 24 06:44 @#$ _!!*Y etc... and do find . -inum 345 -ok rm {} \; ****************** ***** NOTICE ***** ****************** Since my manual did not document the -inum option, and the manual is essentially a reprint of the generic AT&T SystemV manual, it's conceivable that other manuals don't have it either. Check your manual, and if it's not there, see if the option works. If it does, add it and let your O/S maker know. -- Bernie Hoffstadt (503) 752-5929 *** Internet: cutter%cutsys.UUCP@CS.ORST.EDU 1437 N.W. 9th st. -or- 753-1646 *** -or- cutter@jacobs.CS.ORST.EDU Corvallis, Oregon 97330 ****** UUCP: {tektronix,hp-pcd}!orstcs!cutsys!cutter
dnb@brandeis.csnet (David N. Blank) (02/01/88)
[ Will Martin <iunix1@almsa-1.arpa> asks about an easy way to remove
files with control characters in their name.]
My method for dealing with this sort of maverick file is to use the
"dired" package in GnuEmacs (type <esc>-x dired). This allows the
user the point-and-shoot interface that makes manipulation of weird
filenames a piece of cake. I have also been spoiled by this interface
thanks to the "DirUtil" set of programs on my Amiga. I realize this
advice is limited to those who have GnuEmacs at their site, but maybe
it will be useful. For all those who do not have GnuEmacs <sigh>, my
condolences.
Peace
David N. Blank (dnb@brandeis.csnet | blank@brandeis.bitnet)
REMEMBER: It's never too late to have a happy childhood!maxwell@ablnc.ATT.COM (Robert Maxwell) (02/01/88)
In article <3258@psuvax1.psu.edu>, schwartz@gondor.cs.psu.edu (Scott E. Schwartz) writes: > In article <530@celerity.UUCP> jjw@celerity.UUCP (Jim (JJ) Whelan) writes: > > >> find <path> -inum <inode> -exec <command> \; > > >The find will traverse file mount points so you may locate files in file > >systems other than the one you are interested in. Be especially careful > >with using "rm -f" as the command. > > If you are playing with "-inum" it is probably a good idea to use "-xdev" > also, if you want to prevent find from traversing other filesystems. > Do all versions of find support -xdev? 4.3BSD and SunOS3.4 find have it, > at any rate. > System V doesn't have the -xdev option, but recent versions, at least on the 3B2-600 and 3B15 have a -mount option which does the same thing. My users manual for the 3B15 R2.1 doesn't document it, but the option exists in R2.1.1. As the new versions of Sys V are released, I assume the option will show up on other systems. n e w s f o o d . -- ----------------------------------------------------------------------------- Bob Maxwell AT&T DP&CT | All standard (and most non_standard) Maitland, FL ihnp4!ablnc!maxwell | disclaimers apply. -----------------------------------------------------------------------------
caggiano@esquire.UUCP (Frank Caggiano) (02/04/88)
In article <11470@brl-adm.ARPA> iunix1@almsa-1.arpa (Will Martin) writes: > >One common problem we have encountered here in using UNIX-based office >automation systems is people accidentally creating files with odd names, [ Goes on to request info on how to remove the file with the odd name ] >Regards, >Will Martin >wmartin@ALMSA-1.ARPA (on USENET try "...!uunet!almsa-1.arpa!wmartin") Two methods that have always worked for me are: rm -i [some combination of chars to narrow done the list] This will ask you for each file if it should be removed, just skip the ones you don't want removed and answer y to the errant file. Be careful with this however as foo^Ybar and foobar will both show up as foobar. If there are a number of files you want removed or you don't feel like stepping through rm -i use: %ls > filename %vi filename Now remove all lines in the file which do not match the files you want removed then add a rm (or rm -i if you are paranoid) in front of each filename left. exit vi then run %sh filename (or make filename executable and run it) Regards.
wayne@dsndata.UUCP (Wayne Schlitt) (02/04/88)
Posting-Front-End: GNU Emacs 18.44.2 of Tue Jun 2 1987 on dsndata (hpux) > > My method for dealing with this sort of maverick file is to use the > "dired" package in GnuEmacs (type <esc>-x dired). This allows the > user the point-and-shoot interface that makes manipulation of weird > filenames a piece of cake. I have also been spoiled by this interface > of course, dired doesnt handle filenames with trailing blanks like the ones generated by our fix-field cobol friends, but... -- Wayne Schlitt {decuac!super!eecae,psuvax1!super!eecae,ihnp4}!upba!dsndata!wayne
wayne@dsndata.UUCP (Wayne Schlitt) (02/04/88)
> > My method for dealing with this sort of maverick file is to use the > "dired" package in GnuEmacs (type <esc>-x dired). This allows the > user the point-and-shoot interface that makes manipulation of weird > filenames a piece of cake. I have also been spoiled by this interface > of course, dired doesnt handle filenames with trailing blanks like the ones generated by our fix-field cobol friends, but... -- Wayne Schlitt {decuac!super!eecae,psuvax1!super!eecae,ihnp4}!upba!dsndata!wayne
wmartin@almsa-1.arpa (Will Martin -- AMXAL-RI) (02/06/88)
I've gotten quite a few pointers to using "rm -i *" (or some subset of "*") for the remove-weird-named-file problem. However, it doesn't work in every case. I have one right now in my home directory which will show up in an "ls -lt" listing as "?ol?". If I do an "rm ?ol?" or "rm -i ?ol?", I get "rm: hold non-existent" as the response. An "ls -l ?ol?" will get "cannot stat hold" as the response. Notice that the commands can say "hold" in these cases, and not "?ol?". They CAN find this file, but they then cannot work upon it. An "od -c ." will produce output in which I can find the offending file with its name interpreted as "350 o l 344". Interestingly, this file only shows up in an "ls -lt" listing, but not in any other "ls" output I've tried where I don't use the "-t" option. When I let it print on the screen, the filename shows up as "?ol?" but when I redirect the output to a file, the filename comes out "hold", like this: -rw------- 1 wmartin 4781 Jan 11 15:09 hold This file had gotten created by my fumble-fingered typing when I was trying to move a message into a standard message file I normally use named "hold" (I have since moved all the messages out of the real "hold" file and deleted it while this bogus file exists). In short, I thank all those who sent me responses, but I wouldn't have pestered the list if something obvious like "rm -i" would have worked. I understand now that links prevent a simple backwards reference from inode # to filename, and this does answer my original question about why there was no "remove by inode #" option to "rm". At least one respondent sent me a C program which will do this function, though, so it can be done if you know the file doesn't have links. You can also use "find" to do this, and several respondents sent me pointers on that method. I will experiment with them. Since they all seem to rely on "rm" working on the file after you locate it, and, as you can see above, rm can already locate the file but fails in the remove process, I wonder how useful these methods are. One last point -- please note that this originates on the ARPA/MILNET, and, even though you may be reading it in a USENET newsgroup, not everyone has access to things like the "answers to frequently-asked questions" posted in the newusers newsgroups. Those don't exist over here in ARPA mailing-list land. Regards, Will Martin wmartin@ALMSA-1.ARPA (on USENET try "...!uunet!almsa-1.arpa!wmartin")
guy@gorodish.Sun.COM (Guy Harris) (02/06/88)
> However, it doesn't work in every case. I have one right now in my home > directory which will show up in an "ls -lt" listing as "?ol?". If I do an > "rm ?ol?" or "rm -i ?ol?", I get "rm: hold non-existent" as the response. > An "ls -l ?ol?" will get "cannot stat hold" as the response. Notice that > the commands can say "hold" in these cases, and not "?ol?". They CAN find > this file, but they then cannot work upon it. An "od -c ." will > produce output in which I can find the offending file with its name > interpreted as "350 o l 344". The problem here is that most implementations of UNIX command processors ("shells") use the 8th bit of an 8-bit byte internally; they strip this bit off in file names and other arguments to commands. That is why the commands say "hold"; they have been handed the file name with its 8th bit stripped off, and if you strip the 8th bit from octal 350 you get octal 150 which is the code for 'h', and likewise for octal 344 which becomes 'd'. So, in fact, the commands *can't* find the file; the message "cannot stat hold" is issued because they can't find the file "hold" to stat it. This deficiency is fixed in the System V Release 3 version of the Bourne shell, and, I believe, in the "ksh-i" version of the Korn shell. People have also fixed the C shell, but you can't get it from Berkeley in that form. > In short, I thank all those who sent me responses, but I wouldn't have > pestered the list if something obvious like "rm -i" would have worked. "rm -i *" won't work unless you have a shell that doesn't strip off the 8th bit. "rm -i ." should work, because it will try to remove all the files in the current directory before removing the current directory. "rm" will get the names of the files in that directory by itself, without the shell's assistance; "rm" doesn't do anything with the 8th bit, so this is not a problem. "-i" makes it ask before removing any files; "just say no" to all questions, except when it asks you to remove the file you want removed. Note that "rm" will just print the file name as it sees it. Some terminal drivers will strip the 8th bit off, so that file's name will appear as "hold". Others can be told not to strip this bit off; some terminals will then do it for you, so they will display it as "hold". Others will not; if they support the ISO Latin #1 alphabet, they will display it as "\`eol\:a", where "\`e" represents the letter "e" with a "`" accent above it, and "\:a" represents the letter "a" with a diaresis or umlaut above it. Note that the 4.2BSD and 4.3BSD file systems, as provided by Berkeley, disallow file names containing characters with the 8th bit set. However, as this disallows files named e.g. "Citro\:en", where "\:e" represents the ISO Latin #1 charater that is the letter "e" with a diaresis above it, and as such file names may be considered desirable outside the Anglophone world, many vendors will remove this restriction. The most common reason *I* have seen for files with "funny" names is that an executable program for a machine other than the one on which it was run will, most likely, be treated as a command script by the shell on that machine, since it has its execute permission bits set. As more systems adopt Dennis Ritchie's "#!" convention, permitting the kernel to find a command interpreter program that is required for executing a shell script and run that program when the script is "exec"ed, it will be less frequently necessary to have the shells treat any file with execute permissions as a potential shell script. It might be useful to have an option to the shells saying "don't run this if it has execute permission but is not an executable image". Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
dhesi@bsu-cs.UUCP (Rahul Dhesi) (02/07/88)
In article <11667@brl-adm.ARPA> wmartin@almsa-1.arpa (Will Martin -- AMXAL-RI) writes: >An "ls -l ?ol?" will get "cannot stat hold" as the response. Notice that >the commands can say "hold" in these cases, and not "?ol?". They CAN find >this file, but they then cannot work upon it. An "od -c ." will >produce output in which I can find the offending file with its name >interpreted as "350 o l 344". It looks like the eighth bit is set in "h" and "d" in the filename. It may be that you rm program ignores the 8th bit and tries to remove (or stat) "hold" in 7-bit ascii, or that the shell expands your wildcards in 7-bit ascii only. I suggest the following C program: main() { unlink ("\350ol\344"); } -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
guy@gorodish.Sun.COM (Guy Harris) (02/07/88)
> "rm -i *" won't work unless you have a shell that doesn't strip off the 8th > bit. "rm -i ." should work, because it will try to remove all the files in > the current directory before removing the current directory. Well, err, umm, "rm -i ." won't work either, twit. (OK, let's see how many people flame me for insulting the previous poster without first checking to see who the poster I'm insulting is; it's happened before....) "rm -ri ." will, however, at least on some systems; you need the "-r" flag to tell it to remove everything *in* "." as well as removing "." itself. On other systems, it will refuse to remove "."; the 4.[23]BSD "rm" does so, but in 4.[23]BSD the kernel refuses to allow file names to contain characters with the 8th bit set. The only system with which I'm familiar that allows such characters but has the 4.[23]BSD check also has a Bourne shell that doesn't strip off the 8th bit, so that isn't a problem. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
steve@nuchat.UUCP (Nuchia) (02/10/88)
From article <280@cutsys.UUCP>, by cutter@cutsys.UUCP (Bernie Hoffstadt ): [about the find command, and sysV documentation...] > Since my manual did not document the -inum option, and the > manual is essentially a reprint of the generic AT&T SystemV manual, it's > conceivable that other manuals don't have it either. Check your manual, > and if it's not there, see if the option works. If it does, add it and > let your O/S maker know. The reason the reference to -inum was deleted is that the concept of an inumber relates to one specific (well, two, but I digress) implementation of the filesystem. Thus all mention of them (inodes) were expurgated from the SVID. And since all recent sysV manuals are derived from the SVID (choke gasp) they all lack any information on how things work. "From now on, think of it as standard." - someone on the death star. -- Steve Nuchia | [...] but the machine would probably be allowed no mercy. uunet!nuchat!steve | In other words then, if a machine is expected to be (713) 334 6720 | infallible, it cannot be intelligent. - Alan Turing, 1947
guy@gorodish.Sun.COM (Guy Harris) (02/10/88)
> The reason the reference to -inum was deleted is that the concept > of an inumber relates to one specific (well, two, but I digress) > implementation of the filesystem. Thus all mention of them (inodes) > were expurgated from the SVID. And since all recent sysV manuals > are derived from the SVID (choke gasp) they all lack any information > on how things work. 1) The System III manual doesn't mention "-inum" either, and that manual certainly antedates the SVID, since it antedates SV. I assume here that the S3 "find" had "-inum"; the V7 one did (and documented it), and the S5 one did (but didn't document it). It is certainly possible that they picked it up from Research between S3 and S5. Unfortunately, it has been several years since I had S3 source handy, so I can't check this. However: 2) The System V "Release 1" manual also doesn't mention it. The SCCS ID in The S5R1 "find.1" has a date of 5/18/82, while the SVID, Issue 2, has a copyright year of 1986. (Issue 1 didn't have any commands.) The S5R1 "find" definitely *did* have "-inum"; I just checked the S5R1 source. 3) On page 126 of Volume 2 of Issue 2 of the SVID, it says (this is the page for "stat" and "fstat"): The contents of the structure "stat" pointed to by "buf" include the following members: ... ino_t st_ino; /* i-node number */ so it appears that all mention of inodes were not removed from the SVID, unless you consider "i-node"s to be different from "inode"s. 4) The concept of an i-number may relate to some particular file system implementations, but the concept of a unique per-file-system file ID doesn't. From Draft 12 of the POSIX standard: file serial number A "file serial number" is a per-"file system" unique identifier for a "file". "File serial numbers" are not necessarily unique throughout the system. ... 5.6 File Characteristics ... 5.6.1.2 Description The header <sys/stat.h> defines the structure "stat" returned by the functions "stat()" and "fstat()". Member Member Type Name Description ______ ______ _____________________________ ... ino_t st_ino File serial number so saying that i-numbers are peculiar to some particular file system type provides no excuse for leaving "-inum" out; "find -inum" can search for all files with a particular "file serial number". 5) "All recent sysV manuals are derived from the SVID"? Wrongo. The SVID is derived from various flavors of S5 manuals, and there may be some reverse-channel information flow (e.g. as people doing the SVID discover stuff the documentation Doesn't Quite Cover, things may get pushed back into the documentation), but the S5 manuals are *NOT* simply "derived from the SVID". 6) The S5 "find" manual page doesn't mention the "-ncpio" flag, either; this flag is similar to the documented "-cpio" flag, except that it produces "cpio -c" output rather than binary "cpio" output. If you grant that "find -cpio" is useful, you must grant that "find -ncpio" is far more useful, as binary "cpio" output cannot easily be read on machines with a different byte order (no, the byte swapping options in the S5 "cpio" don't help one bit - you *can't* do it with the tools provided with S5, unless you include "ed" or "vi" and "cc" among the tools). So it appears that there are several lacunae in the S5 "find" man page, some of which clearly can't be blamed on the baleful influence of the SVID. The hypothesis that best fits the facts here is that Somebody Just Forgot To Document It.
gore@nucsrl.UUCP (Jacob Gore) (02/11/88)
/ comp.unix.questions / steve@nuchat.UUCP (Nuchia) / 7:26 pm Feb 9, 1988 / >The reason the reference to -inum was deleted is that the concept >of an inumber relates to one specific (well, two, but I digress) >implementation of the filesystem. Thus all mention of them (inodes) >were expurgated from the SVID. And since all recent sysV manuals >are derived from the SVID (choke gasp) they all lack any information >on how things work. Hmm.... So we can't always assume that there are inodes... Suppose I wanted to make a 'prune' option for a program that traverses the directory tree. For example, an 'exclude subtree' option for 'tar', which would take as a parameter a name for the directory at the root of the subtree to be excluded. Now, that may not be the only name for that directory (symbolic links, you know, and stuff like that), so it would help if I could uniquely identify that directory file. Until I saw the above message, I thought that the pair (device, inode) will give me that unique file ID. Is there a general, SVIDable way to do this? Jacob Gore Gore@EECS.NWU.Edu Northwestern Univ., EECS Dept. {oddjob,gargoyle,ihnp4}!nucsrl!gore