I receive windows files via the internet on my solaris server. Since unix doesn't handle blanks well I change the blanks to ? which works just fine. I take these files and ftp them to windows so our analysts can work with them. Recently I received a file with the following structure:

/xxxxx/xxxxx/xxxxx/name_fn_894983489 #2 name2.csv

my shell converted that to:

/xxxxx/xxxxx/xxxxx/name_fn_894983489?#2?name2.csv

and my ftp failed. Actually it didn't but the way I get the file from the server it comes in on to the server my shell is running on is:

rsh cat file.name > localfile

and the cat failed. However when I tried to cat or ls it on the server it resided on it worked. But when I tried to cat or ls it with a rsh it couldn't find the file. That # sign looked questionable so I looked into it and it looks like I'm probably telling it to suppress two bytes of the name.

So my question is does the rsh cause the # sign to resolve whereas if I'm on the server it won't? Does anyone know how this works?

I think having the "#" character there is dodgy because the shell is probably treating the end of the filename as a comment.

I'd also advise against using a "?" as a "regular" character, seeing as it's a shell wildcard - that will end up causing problems somewhere down the line too. Use an underscore instead.

Cheers
ZB

By using the ? mark there I can get away with having spaces in a name as the system looks for anything there. I don't actually rename the files.

FYI Windoze does not understand ? or any special characters
in the names of a file. In case you are putting a ? in the name of a file and FTP it you can (as JazzyBob suggested) place an underscore in the name of the file as against a ?

Cheers