Greetings,

I use the following shell script to concatenate all of the files in a given diretory:

#!/bin/sh
$file
read file
cat *.* > $file

This has worked like a charm so far for files that looked like this xxxxxx, but when I tried to run it in a directory with files in this format xxx-xxxx I get the following error --> cat: *.*: No such file or directory. I am assuming this is a result of the dash in these file names. Could someone help with how to remedy this?

The second line ($file) of your script is useless an do nothing, except if "file" is an exported variable from your calling shell, and then can be pretty damaging ...

Your program is concatenating all files having an extension, so, contrarily to what you are saying, files like xxxxxx are not processed.

Files like xxx-xxxx are not the reason of the error message, but just the fact that in the current directory, no files with extensions are present

jlliagre is right. Use "cat *" instead of "cat *.*". This will also match the "xxxx.xxx" files. In UNIX shells (e.g. sh or bash) wildcards have more finer grained usability than DOS/windows batch files.

Thanks, I'll have to try that out.

However:

(1) My script has served its purpose quite well except for the problem I mentioned (some files not being recognized in the directory). I have noticed no problems in the outputted file of a result of each file being combined into one.

(2) The variable is indeed serving a purpose. The variable is holding the desired filename for the end result of the script, which is a new file containing all of the contents of the other files.

(3) If the way in which I am doing this is not necessary correct procedure to you that is OK with me, because it is a clever hack that serves the purpose for me none the less

(1) wrong, your script as it is cannot save xxxxxx like files
(2) I do not object the variable is not serving a purpose, I just want to warn you that its first use is risky. for example, as root try " # export file=reboot" then run your script.
(3) can you tell more about that clever hack ?

Are you foolish? I mean telling my that my script cannot do something when indeed I have (and am) witnessing it doing the desired result first hand is a fools venture; that kind of thinking is really arrogant. If I told you that the sky is blue here would you argue with me about whether it is indeed that color? Are you here to see it first hand?

Yes I could, but haven't you heard enough? And no I'm not going to get into the semantics of a what a clever hack is.

The sky is blue here bud, try and tell me otherwise and I'll feel free to ignore you.

Sorry, I'm not trying to be rude, but I'm just to open your eyes.

You THINK seeing that script working, and I have no doubt you are sincere, but based on how un*x shells behave, I just can't believe it possible, and trust me, I'm not alone.

If it really happens like you say, you're running a non standard shell on a non un*x O/S, and so you're asking the wrong forum, for example *.* take all files under DOS.

With Unix shells, *.* CAN'T expand to a file not having an extension. full stop.

So the answer to your posting is:

- The error message you are seeing is just an indication of no files with extensions exists in your directory.

- Your assumptions about files with embedded minus signs is wrong, unless the file name have also an embedded space just before the minus sign.

Trust it, and you'll be able to move forward.

If you don't, try the following script to be convinced:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
#!/bin/sh
cd /tmp
mkdir testdir || exit
cd testdir
touch a b c d # create four empty files with no extensions
cat *.* > /dev/null # you'll get an error message like: *.* no such file or directory
echo *.* # you'll get *.* meaning no expansion was done
echo * # you'll get a b c d meaning expansion occured
touch a.a b.b c.c # create three empty files with extensions
cat *.* > /dev/null # you'll get no error message
echo *.* # you'll get a.a b.b c.c
echo * # you'll get a a.a b b.b c c.c d
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Hope this helps.

PS:
The sky is blue over there too.
A clever hack is not that clever when uncommented.

I am not trying to be rude either, and I appreciate the time you have taken, but it really wasn't that necessary.

I never doubted what you said insofar as the proper way to write this script, nor was I disagreement with why my script wasn't working in the case of the files named with the dash (-). What I took issue to was that you were telling me that what was working for me wasn't (non dashed files), instead of what you have just recently written which was that it shouldn't work. There is a difference between the two. And soon I can to the conclusion that the reason I was allowed to do something that shouldn't work was probably because I was running a emulated Linux (Cygwin).

I think Cygwin follows under the category for question's in this forum. In the future I will be sure to be more specific about what OS (or in this case emulated OS) I am running.

Thanks,

Scott

Oh, and I would comment out this hack, but I think between the two of use we have done precisely that

Yes, you are running in a non linux/un*x environment, that certainly explains everything.

File expansion semantics are different with windows, so the cygwin developers had to make a choice about which one to choose.

Perhaps can it be changed through a parameter, though.

You can run the shell script I sent under cygwin to confirm it, the first "cat" command shouldn't triggers an error as it does under linux.