bio_zwbb@jhunix.HCF.JHU.EDU (Dr. William B. Busa) (07/27/89)
I am using some software which has a horrible bug -- it generates data files which have null names; for instance, ls will list these files as (null).001 (null).002 (null).003 etc. These truly are nulls -- in an alphabetical directory listing, they are listed *before* . and ..! My question is this: how can I change these to manageable filenames? I realize that I can address these files as *.001, etc., but this does not solve my problem, because there will be lots of well-formed file names matching the pattern in the same directory. I think I need a solution which will specifically address nulls. Any suggestions? Dr. William B. Busa Dept. of Biology The Johns Hopkins University (301) 338-8207 bio_zwbb@jhunix
chris@mimsy.UUCP (Chris Torek) (07/27/89)
In article <2131@jhunix.HCF.JHU.EDU> bio_zwbb@jhunix.HCF.JHU.EDU (Dr. William B. Busa) writes: >I am using some software which has a horrible bug -- it generates data >files which have null names; for instance, ls will list these files as >(null).001 >(null).002 >(null).003 >etc. These truly are nulls -- in an alphabetical directory listing, >they are listed *before* . and ..! They are not truly `nulls', they are the sequence left-paren n u l l right-paren dot zero zero <digit>. They come before `.' and `..' in sorted directory listings because `(' comes before `.' in ASCII. >My question is this: how can I change these to manageable filenames? % sh # if using csh $ for i in '(null)'.*; do > mv "$i" "`echo \"$i\" | sed 's/(null)/foo/'`" > done The other thing to do is fix the software. Probably a `helpful' C library is receiving a call of the form char *p = NULL; int seq = 0; ... (void) sprintf(buffer, "%s.%3d", p, seq); and instead of crashing the program (thus pointing directly to the bug), it is formatting `%s' with an argument of (char *)0 as the six-letter sequence `(null)'. Suns and 4.3BSD-tahoe machines do this, for instance. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
bio_zwbb@jhunix.HCF.JHU.EDU (Dr. William B. Busa) (07/28/89)
Thanks to all who responded. Responses fell into two categories:
1) Those who accepted my assertion that filenames displayed by
ls as (null).001, (null).002, etc. really did begin with a NUL
character.
2) Those who rejected the possibility of UNIX producing a filename
beginning with a NUL. This was best explained by guy@auspex.com:
"The UNIX calls to create files, etc. take C-language strings as
arguments, and those strings end with '\0', so a call passed the
characters "\0.001" would assume that the string being passed was a null
string "", NOT a string with a '\0' followed by ".001" "
Consequently, as many suggested, it was most likely that my "(null)"
filenames actually contained the characters '(' 'n' 'u' 'l' 'l' ')'; a
sorted ls listing would still place these before . and .. since '(' is
ASCII 40 while '.' is ASCII 46.
This, as it turned out, is exactly correct -- my files did not contain any
NUL characters in the names; rather, they were named "(null).001",
"(null).002", etc. I had been confused by my attempts to change these
names with commands like
mv (null).001 foo.001
which, of course, generated error messages. The simple solution was to
quote the filename:
mv "(null)".001 foo.001
An additional interesting comment was supplied by Chris Torek
(chris@mimsy.UUCP):
"The other thing to do is fix the software. Probably a 'helpful' C
library is receiving a call of the form
char *p = NULL;
int seq = 0;
...
(void) sprintf(buffer, "%s.%3d", p, seq);
and instead of crashing the program (thus pointing directly to the bug),
it is formatting '%s' with an argument of (char *)0 as the six letter
sequence '(null)'. Suns and 4.3BSD-tahoe machines do this, for instance."
I haven't had a chance to check this yet, but it *is* interesting
to note that my buggy software is running on a Sun 3/110 running SunOS 3.3
(4.2BSD).
Again, thanks to all! Sorry the question wasn't *nearly* as
interesting as it originally seemed! gwyn@smoke.BRL.MIL (Doug Gwyn) (07/30/89)
In article <2131@jhunix.HCF.JHU.EDU> bio_zwbb@jhunix.HCF.JHU.EDU (Dr. William B. Busa) writes: >These truly are nulls They can't be. Try invoking "od -c ." to see what's really in the directory. My bet is that you'll see the characters (, n, u, l, l, ), etc., probably produced by a sprintf() that produces that for a %s format spec with a corresponding null pointer argument.
bob@wyse.wyse.com (Bob McGowen x922-4312 Training) (08/01/89)
In article <2131@jhunix.HCF.JHU.EDU> bio_zwbb@jhunix.HCF.JHU.EDU (Dr. William B. Busa) writes: >I am using some software which has a horrible bug -- it generates data >files which have null names; for instance, ls will list these files as ---deleted--- >My question is this: how can I change these to manageable filenames? I >realize that I can address these files as *.001, etc., but this does not >solve my problem, because there will be lots of well-formed file names ---deleted--- If you are using the Bourne shell, the following pattern should work: [!!-~].??? The part to the left of the period says anything that is NOT (first exclamation) in the range exclamation to tilde. This means that ANY control character would be found. Also, only a single character is matched. If there should happen to be more than one null character, you will need more of the patterns (probably just following it with an asterix would work). The part after the period can be any style of pattern that will match the last three characters in the file name. If you must exclude control characters also, you could try making the pattern in a file with vi. Use the ^V escape to enter a ^A (an SOH character, DEC 1 in ASCII character set, follows NULL) and make the pattern be: [!^A-~].??? In this case you would want to build a script around the pattern to do the renaming for you. Bob McGowan (standard disclaimer, these are my own ...) Customer Education, Wyse Technology, San Jose, CA ..!uunet!wyse!bob bob@wyse.com