andre@targon.UUCP (andre) (11/24/88)
In UNIX-WIZARDS Digest V6#021, Jean-Pierre Radley <jpr@dasys1.uucp> writes: >It may be so screwed up that the "*" metacharacter won't expand into such >a bad name (and if the name starts with ".", then the "*" also won't >help). The * metacharacter does expand right, but then the shell strips off the 8th bit. One solution I once found is to use zoo (the archiver) to move the file into an archive, zoo deletes it if all files are added. Then you can remove the archive. So if you have zoo running, use: zoo aM name <first char of name>* rm name.zoo -- ~----~ |m AAA DDDD It's not the kill, but the thrill of the chase. ~|d1|~@-- AA AAvv vvDD DD Segment registers are for worms. ~----~ & AAAAAAAvv vvDD DD ~~~~~~ -- AAA AAAvvvDDDDDD Andre van Dalen, uunet!mcvax!targon!andre
flint@gistdev.UUCP (12/07/88)
ls -b on S5 is the easy to see what the bad char is, not od.
guy@b11.UUCP (Guy Streeter) (12/09/88)
In article <8800004@gistdev> flint@gistdev.UUCP writes: > >ls -b on S5 is the easy to see what the bad char is, not od. ls -b won't help you discover that the filename has spaces or tabs at the begining or end of the visible filename (or, for that matter, a filename made up entirely of spaces and tabs). I consider this to be a bug in the -b option of ls. Guy Streeter ...uunet!ingr!b11!guy (UUCP) ingr!b11!guy@uunet.uu.net (ARPANET)