raulin@tdl.UUCP (Raulin Olivera) (05/10/89)
I posted this last week but didn't get any responses so I am trying it again. Thanks for your patience. This is probably a real dumb question. So my apologies to the real hackers out there. I wrote a "C" program that writes to a text file. I was supposed to put the filename as an argument on the command line. However, I neglected to do so and I failed to include the proper diagnostics in the proper place in the program to exit the program when a filename was not provided. So the program ran and created a real ugly filename. In ascii it looks like k~k^T^Nk^L and in hex it is 6B 7E 6B 14 6B OE 6B OC. I can't figure out any way to remove this file. I would like to be a real man and do it in "C" but I will accept any suggestions in any manner of solution. Thanks =Ralo-> (humbled)
neubauer@bsu-cs.bsu.edu (Paul Neubauer) (05/11/89)
Sorry, all, I tried to reply to this by email, but it bounced. In article <128@tdl.UUCP> raulin@tdl.UUCP (Raulin Olivera) writes: > I posted this last week but didn't get any responses so > This is probably a real dumb question. So my apologies Actually, the problem seems to arise all the time. > to the real hackers out there. I wrote a "C" program > that writes to a text file. I was supposed to put the > filename as an argument on the command line. However, > I neglected to do so and I failed to include the > proper diagnostics in the proper place in the program > to exit the program when a filename was not provided. So > the program ran and created a real ugly filename. In > ascii it looks like k~k^T^Nk^L and in hex it is > 6B 7E 6B 14 6B OE 6B OC. I can't figure out any way > to remove this file. I would like to be a real man > and do it in "C" but I will accept any suggestions in > any manner of solution. Well, it seems to me that writing a C program just to delete one file is a bit of overkill. The easiest way to get rid of it is probably just: rm -i k* where the '-i' prevents rm from rm'ing more files than you want to get rid of and the 'k*' prevents it from asking for ALL of your files. This kind of problem seems to occur with greater than negligible frequency. The other variation of the problem is where you actually have USEFUL data in some file that you can't get at because of bad file names. I once left my brain at home and named a file something like 'odds&ends' (on a BSD system). I just could not persuade csh to recognize that the '&' was to be considered part of the filename -- it just kept putting all of my commands trying to refer to the file into the background. Then, just today I told the mailer that I have been trying lately (elm) to save some mail into a file in a directory other than my home directory. The problem was, that instead of telling it s dir/file I told it: s dir file and wound up with a file in my home directory with a space in its name! (the actual names have been changed to protect the guilty :-) I finally resorted to: cat dir* temp mv temp dir/file As I see it (and this is NOT intended as a flame), this illustrates a problem with the *nix filesystem: filenames can be created that cannot then be sensibly manipulated. I LIKE the flexibility of *nix filenaming where you are not required to have a '.' in all filenames (like some OS's which shall remain nameless) and (at least with BSD) names can be reasonably long, but it can be a hassle when you accidently create a file with a wierd or ugly name and then cannot easily rename or delete it. -- Paul Neubauer neubauer@bsu-cs.bsu.edu neubauer@bsu-cs.UUCP <backbones>!{iuvax,pur-ee}!bsu-cs!neubauer
dlnash@ut-emx.UUCP (Donald L. Nash) (05/12/89)
In article <7170@bsu-cs.bsu.edu>, neubauer@bsu-cs.bsu.edu (Paul Neubauer) writes: > As I see it (and this is NOT intended as a flame), this illustrates a > problem with the *nix filesystem: filenames can be created that cannot then > be sensibly manipulated. I LIKE the flexibility of *nix filenaming where > you are not required to have a '.' in all filenames (like some OS's which > shall remain nameless) and (at least with BSD) names can be reasonably long, > but it can be a hassle when you accidently create a file with a wierd or > ugly name and then cannot easily rename or delete it. This really is not a problem with the UN!X filesystem so much as it is with the UN!X shells. The filesystem is perfectly happy to deal with filenames with ugly characters in them, as is illustrated by all of these unhappy experiences. It is the shells, which assign special meanings to certain characters, which are the root of the problem. I always thought that some combination of backslashes, single quotes, and double quotes would convince a shell to allow any character (other than control characters) in a filename, but maybe I am mistaken. I would like to see something like the \nnn syntax of C put into a shell so I can match any character by its ASCII code. Of course it might be difficult to use the "\" character, since it is already used for quoting, but that can be worked around. Don Nash The University of Texas System Office of Telecommunication Services SMTP: dlnash@emx.utexas.edu, don@nic.the.net BITNET: DON@THENIC UUCP: ...!cs.utexas.edu!emx!dlnash
ked@garnet.berkeley.edu (Earl H. Kinmonth) (05/12/89)
>but maybe I am mistaken. I would like to see something like the \nnn syntax >of C put into a shell so I can match any character by its ASCII code. Of Is this not already in some versions of the korn shell? Earl H. Kinmonth History Department University of California, Davis Davis, California 95616 916-752-1636 (2300-0800 PDT for FAX) 916-752-0776 (secretary) ucbvax!ucdavis!ucdked!cck (email) cc-dnet.ucdavis.edu [128.120.2.251] (request ucdked, login as guest)
guy@auspex.auspex.com (Guy Harris) (05/12/89)
>I once left my brain at home and named a file something like >'odds&ends' (on a BSD system). The same situation arises on non-BSD systems. >I just could not persuade csh to recognize that the '&' was to be >considered part of the filename -- it just kept putting all of my >commands trying to refer to the file into the background. Helpful Hints #1273: if you have a file name containing characters that the shell assigns special significance to, put the file name in single quotes when typing it as a file name: % rm 'odds&ends' This works for the Bourne shell (any not-hopelessly-busted version), the C shell (ditto), and the Korn shell (ditto). (Except that for the C shell this may not work for the "!" character - you have to escape it with "\". Oh well....) >and wound up with a file in my home directory with a space in its name! See previous hint: % rm 'dir file' >As I see it (and this is NOT intended as a flame), this illustrates a >problem with the *nix filesystem: filenames can be created that cannot then >be sensibly manipulated. I LIKE the flexibility of *nix filenaming where >you are not required to have a '.' in all filenames (like some OS's which >shall remain nameless) and (at least with BSD) names can be reasonably long, >but it can be a hassle when you accidently create a file with a wierd or >ugly name and then cannot easily rename or delete it. Yup. However, not all users are necessarily using a "traditional" command language to get at the system; it's nice that if they want to stick blanks or "&"s or whatever into their file names, they can do so. There's a separate problem with characters with the 8th bit set, or multi-byte characters one or more of whose bytes have the 8th bit set; some older versions of the shells use that bit internally for quoting, and strip it off before passing it to the command. One might ask "but why would you have such a character in a file name"; the answer is "if, for example, you're keeping some information about Citr\:oen ("\:o" being "o with a diaresis"), you might want to call name the file after the car and (former) company in question; the ISO Latin #1 character for "o with a diaresis" has the 8th bit set". The S5R3 and later Bourne shell, and the "ksh-i" and later Korn shell, don't use the 8th bit for quoting, and thus can deal with file names of that sort (assuming you can type them into your system, which you can with certain terminals/keyboards and software). The C shell may be able to do that as well in some future version. The 4.[23]BSD file system disallows such characters, presumably to prevent people from creating hard-to-remove files of that sort; however, it's again a case of "why disallow it, since somebody might legitimately want to use it", and the SunOS 4.x version of that file system allows such characters, as will the S5R4 version.
wolfgang@mgm.mit.edu (05/12/89)
The best method I know of to remove files with shell meta-chars, spaces etc. in their name is with M-x delete-file in GnuEmacs (you even get filename completion, for those thesis-lenght filenames.) -wolfgang --- Wolfgang Rupprecht ARPA: wolfgang@mgm.mit.edu (IP 18.82.0.114) TEL: (703) 768-2640 UUCP: mit-eddie!mgm.mit.edu!wolfgang Wolfgang Rupprecht ARPA: wolfgang@mgm.mit.edu (IP 18.82.0.114) TEL: (703) 768-2640 UUCP: mit-eddie!mgm.mit.edu!wolfgang
joe@hanauma.stanford.edu (Joe Dellinger) (05/12/89)
Even "rm -i *" used to be dangerous. There is the famous case where somebody accidentally created a file name "-f", and decided to remove it by doing "rm -i *". The csh dutifully expanded this to "rm -i -f [files...]", and at that time "-f" overrode "-i" in rm. Result: everything in the directory deleted EXCEPT the file "-f"! Now -i overrides -f in rm, at least, but rm still interprets files beginning with a "-" as options instead of file names, even when expanded by the csh. I guess poor rm has no way of knowing. In another similar vein, I have a friend that recently had a junk directory created by some sort of nasty low-level software error on a Sun 3. It was like a black hole in the file system; you could cd into it but "cd .." would then just leave you there. If you did "rmdir" it would complain the directory wasn't empty. If you did "rm -r" it would go into an infinite loop trying to work down to the bottom of the infinite pit, and would finally core dump. "fsck" thought there was nothing wrong with the directory. We were really puzzled with this one, but finally the little-used "clear inode" command followed by a fsck did the trick. It was such a wonderful unique object, it was almost a shame to kill it. \ /\ /\ /\/\/\/\/\/\/\.-.-.-.-.......___________ \ / \ / \ /Dept of Geophysics, Stanford University \/\/\.-.-....___ \/ \/ \/Joe Dellinger joe@hanauma.stanford.edu apple!hanauma!joe\/\.-._
dougf@dougf.Caltech.Edu (Doug Freyburger) (05/12/89)
Try: cd .. rm -i -r you_dir And answer "n" to everything but the one that doesn't print readably. dougf@wega.caltech.edu Douglas J Freyburger Caltech 206-49 Pasadena, CA 91125 (818)356-2913
chris@mimsy.UUCP (Chris Torek) (05/14/89)
In article <2214@Portia.Stanford.EDU> joe@hanauma.stanford.edu (Joe Dellinger) writes: >Even "rm -i *" used to be dangerous. There is the famous case where >somebody accidentally created a file name "-f", and decided to remove >it by doing "rm -i *". The csh dutifully expanded this to >"rm -i -f [files...]", and at that time "-f" overrode "-i" in rm. >Result: everything in the directory deleted EXCEPT the file "-f"! Thus, to be safe against old versions of `rm', use rm -i ./* or, in this case more simply, rm ./-f -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
jiii@visdc.UUCP (John E Van Deusen III) (05/14/89)
In article <12970@ut-emx.UUCP> dlnash@ut-emx.UUCP (Donald L. Nash) writes: > > It is the shells, which assign special meanings to certain characters, > which are the root of the problem. I always thought that some > combination of backslashes, single quotes, and double quotes would > convince a shell to allow any character (other than control characters) > in a filename ... When your back is up against the wall, the following construct can be used to replace any argument and will allow you to do anything you want: "`echo '\xxx\xxx\xxx\c'`" where xxx is any octal number. -- John E Van Deusen III, PO Box 9283, Boise, ID 83707, (208) 343-1865 uunet!visdc!jiii
chris@mimsy.UUCP (Chris Torek) (05/15/89)
In article <535@visdc.UUCP> jiii@visdc.UUCP (John E Van Deusen III) writes: >When your back is up against the wall, the following construct can be >used to replace any argument and will allow you to do anything you want: > > "`echo '\xxx\xxx\xxx\c'`" > >where xxx is any octal number. Only if you are dealing with a broken SysV echo (echo should *not* do escape interpretation, and even `echo -n' is iffy); and even then you may have trouble generating meta characters (values in 0200..0377) if you have an older shell. If you have a working echo, use printf(1): "`printf %s '\xxx\xxx\xxx'`" This still may not be able to name meta characters (depending again on the vagaries of your particular shell). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
ked@garnet.berkeley.edu (Earl H. Kinmonth) (05/15/89)
>When your back is up against the wall, the following construct can be >used to replace any argument and will allow you to do anything you want: > > "`echo '\xxx\xxx\xxx\c'`" > >where xxx is any octal number. Are you sure that all version of echo will do this? I was under the impression that this was a Sys-V "feature" picked up in some, but not all, versions of **IX. Also, do not some versions of **IX have more than one echo - one that will do this sort of thing and one that will not? Earl H. Kinmonth History Department University of California, Davis Davis, California 95616 916-752-1636 (2300-0800 PDT for FAX) 916-752-0776 (secretary) ucbvax!ucdavis!ucdked!cck (email) cc-dnet.ucdavis.edu [128.120.2.251] (request ucdked, login as guest)
m5@lynx.uucp (Mike McNally) (05/15/89)
In article <17509@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >Only if you are dealing with a broken SysV echo (echo should *not* do >escape interpretation, and even `echo -n' is iffy . . . Gee, I hadn't thought about this. My echo has a "-v" switch that puts a \n between each argument instead of a space (so it's easy to tell how arguments are broken up by shells and things). I guess the point Chris raises is that echo should be a thing that prints all arguments no matter what. Good idea. I'll change mine and find printf. Live and learn. -- Mike McNally Lynx Real-Time Systems uucp: {voder,athsys}!lynx!m5 phone: 408 370 2233 Where equal mind and contest equal, go.
derek@hsi.UUCP (Derek Lee-Wo) (05/16/89)
In article <1614@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: :Helpful Hints #1273: if you have a file name containing characters that :the shell assigns special significance to, put the file name in single :quotes when typing it as a file name: : : % rm 'odds&ends' : This doesn't work for filenames that start with a minus. eg -badfile Anyone know how to erase such files with whipping up a short C program? -- +-----------------------------------------------------------------------------+ |Derek Lee-Wo (Co-op), Health Systems International, New Haven, CT 06511. | |E-mail address :- derek@hsi.com ...!yale!hsi!derek | +-----------------------------------------------------------------------------+
nobody@orca.WV.TEK.COM (-for inetd server command) (05/16/89)
From: dougb@mustang.WV.TEK.COM (Doug Becker;685-2062;61-277;;mustang)
Path: mustang!dougb
As Guy Harris pointed out, in a correction to my second posting:
>> I of course meant 'rmdir -rf,' not 'rm -rf'.
>
> No, you didn't; "rmdir" generally doesn't take "-r" or "-f" flags, even
> if it may happen to do so on your system.
Guy's right, of course, and I for my part have discovered a new level
of embarrassment: posting an article with the 'right' (for some definition
of right) answer, then apologizing for it being wrong and posting an answer
that probably won't work on *ANY* system. My heartfelt apologies to everyone
who vainly tried my second [rmdir] suggestion.
And to think it wasn't even a Monday when I posted...
--- Doug
==================================DOUGLAS H. BECKER=============================
domain mailers: |
dougb@{orca|shark|hammer}.WV.TEK.COM | US Mail: Software Engineer, ITD
UUCP (avoid): | Tektronix, Inc.
{anywhere}!tektronix!tekecs!orca!dougb | P.O. Box 1000
ARPANET: | Mail Station 61-277
dougb%orca.WV.TEK.COM@RELAY.CS.NET | Wilsonville, OR 97070-1000
CompuServe: GEnie: | U.S.A.
72711,1753 D.BECKER10 |
==========================================+=====================================jiii@visdc.UUCP (John E Van Deusen III) (05/16/89)
In article <17509@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: > In article <535@visdc.UUCP> I wrote: >> ... the following construct can be used to replace any argument: >> >> "`echo '\xxx\xxx\xxx\c'`" >> >> where xxx is any octal number. I would like to correct this to read "the System V construct ... "`echo '\0xxx\c'`" where xxx is zero to three octal digits." > > Only if you are dealing with a broken SysV echo (echo should *not* do > escape interpretation, ...) ... and even then you may have trouble > generating meta characters (values in 0200..0377) if you have an older > shell. If you have a working echo, use printf(1): > > "`printf %s '\xxx\xxx\xxx'`" > Is there a particular SysV echo that is broken, or are you saying that System V echo is broken, in general, because, in your opinion, it should *not* do escape interpretation? I do not consider a command "broken" if it does what the manual says it will do and does not do anything else. The ability to put any pattern of bits into an argument more than compensates, in my opinion, for the inconvenience of entering two back slashes when escape interpretation is not intended. If you prefer to use the separate command printf(1), not included with system V, fine. The system V echo(1) command will generate octal values in the range 0-0377 and write them to the standard output file. -- John E Van Deusen III, PO Box 9283, Boise, ID 83707, (208) 343-1865 uunet!visdc!jiii
stjohn@oswego.Oswego.EDU (Dave St. John) (05/16/89)
In article <448@hsi86.hsi.UUCP> derek@hsi86.UUCP (Derek Lee-Wo) writes: > >This doesn't work for filenames that start with a minus. eg -badfile >Anyone know how to erase such files with whipping up a short C program? RTM, it says to use a - for file names that begin with a -. So you would type % rm - -badfile --------------------------------------------------------------------------- UUCP: {your favorite backbone}!sunybcs!oswego!stjohn INTERNET: stjohn@oswego.oswego.edu (129.3.1.1) US Mail: Dave St. John Instructional Computing Center SUNY College at Oswego Oswego, N.Y. 13126 Armadillo: to provide weapons to Spanish pickles ---------------------------------------------------------------------------
johnk@grebyn.COM (John Kennedy) (05/16/89)
Here's how I remove files with ugly names
1) First, do a ls -l on the directory containing the ugly file, yielding
something like:
-rw-r--r-- 1 uglyowner 39 Apr 25 08:00 uglyname
2) Then, select some fairly unique attributes of that file, such
as the owner and size, maybe the creation date, etc.
3) Verify that no other files share these attributes, by
find <directory> -user uglyowner -size 39c -print
4) When you satisfied that you have uniquely described the ugly file,
change the above line to
find <directory> -user uglyowner -size 39c -exec rm {} \;
This should get rid of the ugly file without having to name it.
--
John Kennedy | Second Source, Inc.
johnk@opel.UUCP | Annapolis, MDscowles@lll-lcc.UUCP (Sid Cowles) (05/16/89)
Followup-To> comp.unix.xenix
Diwtribution: usa
Organization: Lawrence Livermore Labs, env sci div, Livermore CA
Lines: 90
Xref: lll-lcc comp.unix.xenix:6756 comp.unix.questions:15401 comp.unix.wizards:17328
Summary:
Expires:
Sender:
Followup-To:
i got hit with this general problem this$weekend in a major way. an
archive job using cpio went haywire and created over 950 files (all
empty) with names including the full range of characters from \0001 to
\0377 in my home directory. my system is too small to have copied all
the bona fide material to another directory and then remove the old
directory containing the garbage, so, i did have to find a way to
remove the "ugly file names".
the problems$i hit were, that in spite of using ,as far as i know) all
the tricks mentioned during this discussion to get the names to /bin/rm,
rm complained that the specified files did not exist. (on top of all
that, ls wouldn't list the contents of the directory because there were
too many files. no, not fun.) and, no, using find to feed the names
to rm with an imbedded exec fared no better. what i ended up doing, wasreferring to the files by their inodes and dispensing with shell
problems vis-a-vis the control and$meta characters, altogether. it's a
messy procedure that relies on clri followed by fsck to wipe the cleared
inodes (su priveleges needed, etc.). if anyone has a simpler, verified,
method for accomplishing this task, i'd certainly like to hear of it.
at this stage, m invite being slown the error of my ways.
until then, for anyone who would like to critique it, the method i ended
up with follows.
sid
=======================================================================
s cowles
uucp: {backbone}!lll-lcc!scowles
internet: scowles@lll-lcc.llnl.gov
=======================================================================
proflem: remove files whose names mnclude characters outside
the range of decimal ascii 32 to 126.
rm may complain about files with such characters, issuing suchresponses as file not found, etc. the normal tricks like
1) cd to_problem_directory 2) /bin/rm -i ./* won't work in some
of these cases; rm refuses to recognize some of the file names.
on small systems, the available space may be so small that
copying the keep portions of the problem directory to a new
location may not be possible. short of restoring from backup,
the following offers an alternative. the salient feature is
removal by reference to the inode instead of the file name. this
technique uses clri which may not be available on all systems.
tle problem files are identified by using an editor. for large
numbers of files ,ie, several hundred), interactive responses for
each file are much slower than mass processing in an editor.
all scripts shown use$the bourne shell.
# step 0: go to single user state (in anticipation of steps 5 and 6).
# step 1: cd to the problem directory and list all file names
cd $problem_directoryfor file in .??* *
do
echo "./$file"
done | sort > /tmp/filenames
# step 2: examine the file names in filenames with some editor
# and record the line ranges of the files to be blitzed.
# do not alter the original filenames file, mtself.
# step 3: make a list of the files for removal by concatenating
# the lines of filenames containing the file names for
# removal. be careful not to use a 7-bit editor that
# might chop eighth bits in the file names. (i use a
# small c program called catln that passes lines within
# a range analogous to: sed -n 'n1,n2p'.)
>/tmp/fn_removes
catln 1 282 filenames >> /tmp/fn_removes
catln 318 459 filenamew >>$/tmp/fn_removes
etc
# step 4: get the inodes of the problem files:
cd $problem_directory
> /tmp/fn_inodes
cat /tmp/fn_removes |
while read file
do
/bin/ls -i "$file"
echo "" # some file names may suppress the ls new line.
done | awk '{print $1}' | sed '/^$/d' >> /tmp/fn_inodes
# step 5: blitz the selected inodes.
/etc/clri $file_system_spec_dev `cat fn_inodes`
# step 6: perform a file system check on the alterred system
# with fsck to fix the mess left by clri
# step 7: resume normal usage.
=======================================================================rta@pixar.UUCP (Rick Ace) (05/16/89)
Removal of files with names containing non-ASCII characters is addressed in item 10 of "Answers to Frequently Asked Questions" in the newsgroup news.announce.newusers. The foreword of that article appears below. > Frequently Submitted Items > > This document discusses some items that occur repeatedly on USENET. > They frequently are submitted by new users, and result in many > followups, sometimes swamping groups for weeks. The purpose of this > note is to head off these annoying events by answering some questions > and warning about the inevitable consequence of asking others. If you > don't like these answers let spaf@purdue.edu know. Rick Ace
jackh%twinpeaks@Sun.COM (John Hevelin) (05/17/89)
This has always worked for me, but I haven't
tested it against every conceivable possibility.
1. I use "ls -i" to obtain the i-number of the ugly
file:
% ls -i
12345 ugly'"^H^G& 98765 goodfile2
67890 goodfile1 43210 xyzzy
2. Then I use "find" to remove the file:
% find . -inum 12345 -exec rm {} \;
3. If I want to save the contents of the file before
removing it, I do something like:
find . -inum 12345 -exec cat {} \; > goodfileguy@auspex.auspex.com (Guy Harris) (05/17/89)
>This doesn't work for filenames that start with a minus. eg -badfile >Anyone know how to erase such files with whipping up a short C program? Yes, I think just about *anybody* reading any of these groups who is familiar with the "unlink" system call can do it trivially. However, there are better ways to remove "-badfile" as well. Both the BSD and S5 versions (S5R3 and later, and least, and, I suspect, S5R2 and maybe earlier as well) have flags to say "nothing after this is a flag, even if it begins with a "-"; in the BSD version, the flag is "-", and in the S5 version, the flag is "--" (since the S5R3 version, and possibly other versions, use "getopt", which handles "--" for the program using it). So, you can do bsd$ rm - -badfile s5$ rm -- -badfile If your "rm" doesn't have something like that, you can do loser% rm ./-badfile
rdb@osf.OSF.ORG (Ron Birnbaum) (05/17/89)
In article <1233@oswego.Oswego.EDU> stjohn@oswego.oswego.edu.Oswego.EDU (Dave St. John) writes: >In article <448@hsi86.hsi.UUCP> derek@hsi86.UUCP (Derek Lee-Wo) writes: >> >>This doesn't work for filenames that start with a minus. eg -badfile >>Anyone know how to erase such files with whipping up a short C program? > >RTM, it says to use a - for file names that begin with a -. >So you would type > % rm - -badfile Or else you can remove another file with -badfile on the same line: rm another -badfile will remove the files 'another' and '-badfile'. >US Mail: Dave St. John -Ron Birnbaum rdb@osf.org
gandalf@csli.Stanford.EDU (Juergen Wagner) (05/17/89)
Sigh! There we go again...
You can delete files with the `rm' command, or with the following C program:
# define FILE "..." /* name of file to remove */
main()
{
if (unlink(FILE) < 0)
perror("unlink");
exit(0);
}
Let's call this program "do-rm".
Ok, now here are the cases:
[1] Files with ASCII characters (20h..7eh) in their names:
Cd to the directory containing the file to be removed. Execute
/bin/rm './FILE'
where FILE is the name of your file. If your file name contains
single quotes, you have to use a more tricky quoting scheme, e.g.
/bin/rm './-foo'"'"' bar'"'"
will remove the file named
-foo' bar'
from your currect directory. Don't forget to put backslashes in
front of '!'s (if you're in csh).
[2] Files with characters in the range 01h..1fh, 7fh in their names:
The same method as under [1] is applicable, but now the non-printing
characters have to be included in the file name. Non-printing
characters can be typed by using ^V to prevent interpretation.
(^V is the lnext character, it can be set with stty). Note that
newline characters (0ah) have to be preceded with a '\'.
[3] Files with characters in the range 80h..ffh in their names:
Most shells don't like the idea of having 8-bit characters, i.e.
shell commands won't work, even if you manage to get the correct
characters into the argument. In such cases, the above C program
can be used (short of clri and fsck).
I hope that helps to clarify the situation. If you [the reader] have any
comments on this posting, please reply to me. DON'T POST YOUR REPLIES.
--
Juergen Wagner gandalf@csli.stanford.edu
wagner@arisia.xerox.comgandalf@csli.Stanford.EDU (Juergen Wagner) (05/17/89)
[Sorry for rising this topic again...] In article <105096@sun.Eng.Sun.COM> jackh@sun.UUCP (John Hevelin) writes: > ...[ways of deleting files]... Several alternatives have been suggested to uniquely identify the file to be removed. However, there are cases in which `rm' won't do the job of deleting the file because the shell which is used to run `rm' may strip the eighth bit off characters [some shells do]. In such cases, it is impossible to remove the file with `rm'. You could do a clri and fsck but that is a little bit of overkill. A short C program will do (see my other posting). -- Juergen Wagner gandalf@csli.stanford.edu wagner@arisia.xerox.com
dgp@ncsc1.ATT.COM (Dennis Pelton x8876) (05/17/89)
In article <448@hsi86.hsi.UUCP>, derek@hsi.UUCP (Derek Lee-Wo) writes: > In article <1614@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > :Helpful Hints #1273: if you have a file name containing characters that > :the shell assigns special significance to, put the file name in single > :quotes when typing it as a file name: > : % rm 'odds&ends' > > This doesn't work for filenames that start with a minus. eg -badfile > Anyone know how to erase such files with whipping up a short C program? > Derek Lee-Wo (Co-op), Health Systems International, New Haven, CT 06511 The construction # rm foo any-other-file will remove any-other-file even if it starts with a '-' sign. This assumes that either foo does not exist or you don't care if it doesn't exist. What happens is that rm assumes, once it gets a non-negative (:-) argument, that all succeeding arguments are file names. Dennis Pelton att.com.UUCP!ncsc5!dgp
jeff@quark.WV.TEK.COM (Jeff Beadles;X2568;61-215) (05/17/89)
In article <448@hsi86.hsi.UUCP> derek@hsi86.UUCP (Derek Lee-Wo) writes: >This doesn't work for filenames that start with a minus. eg -badfile >Anyone know how to erase such files with whipping up a short C program? [ I removed comp.unix.wizards, it doesn't apply... ] Most versions of rm will allow this to work: rm - -badfile The single '-' says "No more command options" To use other command options, use something like: rm -f - -badfile -Jeff -- Jeff Beadles Utek Sustaining Engineering, Tektronix Inc. jeff@quark.WV.TEK.COM
markk@sigma.UUCP (Mark Kimmerly) (05/18/89)
In article <448@hsi86.hsi.UUCP> derek@hsi86.UUCP (Derek Lee-Wo) writes: > >This doesn't work for filenames that start with a minus. eg -badfile >Anyone know how to erase such files with whipping up a short C program? Try 'rm - -badfile' The first '-' tells rm to treat everything that follows as arguments, not options. -- Mark Kimmerly markk@sigma.UUCP Summation Inc. 1-206-823-7964
turtle@sdsu.UUCP (Andrew Scherpbier) (05/18/89)
In article <448@hsi86.hsi.UUCP> derek@hsi86.UUCP (Derek Lee-Wo) writes: >In article <1614@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >:Helpful Hints #1273: if you have a file name containing characters that >:the shell assigns special significance to, put the file name in single >:quotes when typing it as a file name: >: >: % rm 'odds&ends' >: > >This doesn't work for filenames that start with a minus. eg -badfile >Anyone know how to erase such files with whipping up a short C program? Besides being able to do this: rm ./-badfile you can also do rm -- -badfile --Andrew "Race Turtle" Scherpbier
frankb@usource.UUCP (Frank Bicknell) (05/18/89)
In article <7170@bsu-cs.bsu.edu>, neubauer@bsu-cs.bsu.edu (Paul Neubauer) writes: > Sorry, all, I tried to reply to this by email, but it > bounced. My pathalias didn't know about tdl either. Don't feel bad. > Well, it seems to me that writing a C program just to delete > one file is a bit of overkill. The easiest way to get rid > of it is probably just: [ stuff deleted ] True, it's easy, but it does get _rid_. A c program called 'fix' is handy to rename such a file. I'm not sure I should post it here since it's probably available at some archive facility, etc... If enough requests arrive, I'll do so, though. Anyway, it's simple: appeared in the Feb '87 issue of UnixWorld magazine (p. 97). It takes an argument of inode number and changes said filename to 'fix.out'. Handy to have around. > As I see it (and this is NOT intended as a flame), this > illustrates a problem with the *nix filesystem: filenames > can be created that cannot then be sensibly manipulated. I > LIKE the flexibility of *nix filenaming where you are not > required to have a '.' in all filenames (like some OS's > which shall remain nameless) and (at least with BSD) names > can be reasonably long, but it can be a hassle when you > accidently create a file with a wierd or ugly name and then > cannot easily rename or delete it. Don't forget that it was that very flexibility which allowed you to get out of the mess in the first place! Try something like del *xn* on (nameless) and see how far it gets you! This, too, is not intended as returned flame or even dousing... just trying to put things in perspective. You _can_ get stupid filenames in (nameless) also... haywire applications, etc. Try getting rid of them with (nameless) utilities, though! -- Frank Bicknell; 1405 Main St, Ste 709; Sarasota, FL 34236-5701 killer!usource!frankb
ghe@nucthy.physics.orst.edu (Guangliang He) (05/18/89)
In article <3802@sdsu.UUCP> turtle@sdsu.UUCP (Andrew Scherpbier) writes: =In article <448@hsi86.hsi.UUCP> derek@hsi86.UUCP (Derek Lee-Wo) writes: = =you can also do = = rm -- -badfile = But this trick don't work on the BSD4.3. It has a broken 'getopt' function :-) :-) ----------------------------------------------------------------------- | USMAIL: Guangliang He | INTERNET: ghe@PHYSICS.ORST.EDU Department of Physics | ghe@jacobs.CS.ORST.EDU Oregon State University | BITNET: hegl@orstvm.bitnet Corvallis, OR 97331 | PHONE: (503) 754-4631 | -----------------------------------------------------------------------
ccea3@rivm.UUCP (Adri Verhoef) (05/19/89)
>1. I use "ls -i" to obtain the i-number of the ugly file >2. Then I use "find" to remove the file: > % find . -inum 12345 -exec rm {} \; If your terminal gets stuck (or bananas) when listing the directory containing the offending filename (so "rm -i" gets you stuck, too), You might want to try: 1. od -c directoryname_containing_offending_entry 2. rm -f ./"`echo 'offending_filename_in_octal_codes'`" Provided your echo echoes e.g. '\0321' as the corresponding value of the octal char \121 (i.e. 'Q') with its high order bit set.
fr@icdi10.UUCP (Fred Rump from home) (05/22/89)
I think we've just about exhausted the bad file name issue here. From the
hundreds of messages that have challenged the ingenuity of many, one can
easily tell that there are two sets of users out there.
First there are those who simply do what comes natural and then there are
those who make life difficult for themselves and the rest of the world.
Many of our ordinary, un-schooled and un-computer educated users create crazy
files all the time by accident. They don't even think of this as a problem.
They simply go to their friendly little word processor (Lyrix) and delete or
rename to their heart's content by picking from the list of files available to
them using nothing but an arrow key.
We should remember that most users out there may think that grep is some kind
of dirty grope for unnamed body parts. And I suppose that shows that all is
well in computerland. They simply do their work from their friendly little
menus while we continue to fight the valiant battle the press keeps talking
about: how difficult it is to run Unix. Hmmm!
Fred Rump
--
{allegra killer gatech!uflorida decvax!ucf-cs}!ki4pv!cdis-1!cdin-1!icdi10!fr
26 Warren St. ...{bellcore rutgers bpa uunet}!cdin-1!icdi10!fr
Beverly, NJ 08010 or INTERNET: fred@cdin-1.uu.net or fr@icdi10.UUCP
609-386-6846 "Freude... Alle Menschen werden Brueder..." - Schillerallbery@ncoast.ORG (Brandon S. Allbery) (05/23/89)
As quoted from <9000@csli.Stanford.EDU> by gandalf@csli.Stanford.EDU (Juergen Wagner): +--------------- +--------------- That we do. +--------------- | /bin/rm './FILE' +--------------- Thank you. I was wondering how many times I'd have to read putative "wizards" suggesting the nonexistent-filename kluge. Did I fall into a net.warp into comp.unix.questions? +--------------- | characters can be typed by using ^V to prevent interpretation. | (^V is the lnext character, it can be set with stty). Note that +--------------- He directs followups to comp.unix.xenix, then pulls this boner. REALITY CHECK FOR ALL THOSE WHO BELIEVE IN "There Is No Unix But Unix And Berkeley Is Its Prophet": XENIX IS BASED ON AT&T SYSTEM III/V! There IS no "lnext" character. Just type the control character. It won't show up on your terminal, but it'll be there. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
jik@athena.mit.edu (Jonathan I. Kamens) (05/23/89)
In article <31925@sri-unix.SRI.COM> ghe@nucthy.physics.orst.edu (Guangliang He) writes: >= rm -- -badfile > >But this trick don't work on the BSD4.3. It has a broken 'getopt' function >:-) :-) I'm not sure whether or not the smileys are to indicate that you know you are incorrect here, so I'll just have to correct you anyway. rm.c under BSD 4.3 does *not* use getopt at all; if it did, the -- argument would work. In fact, BSD 4.3's version of rm was written before getopt even existed, I would bet. BSD 4.3 Tahoe, on the other hand, uses getopt and therefore gets things right and -- will work. - will also work, but will generate a spurious error message since rm will try to delete the file - and *then* delete the file after it. Jonathan Kamens USnail: MIT Project Athena 410 Memorial Drive, No. 223F jik@Athena.MIT.EDU Cambridge, MA 02139-4318 Office: 617-253-4261 Home: 617-225-8218
guy@auspex.auspex.com (Guy Harris) (05/24/89)
>There IS no "lnext" character. Just type the control character. It won't >show up on your terminal, but it'll be there. Even if the control character happens to be, say, your interrupt character, or ^S, or....?
dbb@riscy.dec.com (David Barrett) (05/24/89)
I've found that the best way to remove files whose names begin with strange characters like a `-' prompt% rm ./-filename or: prompt% rm /usr/users/me/-filename Hope this helps... Dave Barrett