Originally posted by: LYLYY

Hi

I have problem in writing csh script, It doesn;t work in aix. I use "*" as asymbol but in aix it was understand as a wildcard, I use :q but it  doesn't help me.

Originally posted by: Wouter Liefting

Any particular reason to write your shell scripts in the csh? Why not generic sh or ksh?

Wildcards are interpreted in the shell, not by the command that you try to execute (unless you escape them from the shell so that they get passed verbatim to the command, and the command is able to interpret them, for example find / -name '*.bak') or by the AIX kernel. Every shell has different rules on stuff like wildcard interpretation. Sometimes the differences are subtle (bash vs. ksh) and sometimes they are not so subtle (ksh vs. csh).

If you are used to working with the ksh - which is the AIX default shell - it makes most sense to write your scripts for the ksh as well. Which is forced by using #!/bin/ksh at the first line.

From a quick search on the internet it sounds like wildcards work more or less the same in both csh and ksh. You might want to check the setting of your "noglob" variable, which controls whether wildcards are expanded to filenames or not.

And :q sounds like a vi command to me, not a wildcard or wildcard extension.

Can you paste some code, to let us know what you are trying to do?

Originally posted by: LYLYY

Wouter thank you for your comment. This is the part from script.

endif

It works fine in other platforms. I can't write in other versions of shell, because I modifying the already exist script.

Originally posted by: Wouter Liefting

If it works on other platforms, what versions of the csh (both in AIX and on the other platforms) are you using?

Anyway, I'm not an expert on the csh but from what I can see it looks like you are trying to achieve the following: Your script is passed a number of parameters which each represent a filename OR a wildcard expression of some sort. You're expanding the wildcards within the csh, and for each of the filenames you're doing a grep to find something. If that something is found, you mess about with a few $status variables to record that.

If I ignore the grep & status part (which seems to work fine) and just write a shell script like this:

and I call this script with ./test.csh "*" (thus forcing the csh to expand the wildcard, instead of my current shell - bash), the results are NOT what you are trying to achieve. It seems the :q forces the ($argv:q) argument to be one argument, where all filenames are space-separated in a single string. So the foreach loop only iterates once.

On the other hand, if I simply use ($argv), a proper list results, and the foreach loop iterates over each list element once. It even works properly in the presence of filenames and directory names that contain spaces.

This is on Linux (CentOS 6.4, with the tcsh version 6.17.00 - I don't have an AIX system to hand right now) but it's consistent with what the csh manual page tells me. So I doubt you're on the right track with your :q solution. To make sure, I'd put in a few echo lines like above, to see what the $i variable is really doing.

I also see something else wrong with your script. You're currently testing whether $#argv >= 2. Which means that if only one argument is passed, the foreach will not execute - not even when that single argument is "*", which may expand to 1000s of filenames. Unless the first argument is, or can be, a flag of some sort, I'd say you need to test whether $#argv >= 1. And if the first argument is a flag which is handled earlier on in your script, you'd need to do something (a "shift" perhaps) to get rid of that first argument properly before calling the loop. (The script may work fine now since you're testing whether the argument exists as a file later on, but what would happen if you accidently created a file with the same name as your flag?)

Another thing is that you're using -e, presumably to test if the file exists. It might be better to use -r or even -f and -r. The single fact that the file exists may not mean that the grep is going to be successful. It may be a directory or special file, or you may not have read permissions.

Hope this helps.