/home/adw/a.ksh << EOF
a
b
EOF
This is how we give input to a file through script
Our client has done the coding in a different way :-
/home/adw/a.ksh << **
a
b
Can nybody pls tell me the significance of **
Just assigns a wildcard to accept any input as the input file...
In your case it is waiting for 2 files.
Waiting for 2 files? What does that mean?
My experiments with ksh on HP-UX show that ** in this case is treated exactly like EOF. The shell will read input until the line with ** is reached. No wildcard expansion seems to be done. This is a really odd syntax though. Other shells might behave differently.
I think that it would be a good idea to *not* use any shell wildcards (such as *, ?, etc.) in the input redirection. Better stick to normal characters. I prefer using '!'.
It works the same way as described by Perderabo for Solaris with sh, ksh, bash, csh and tcsh.
For every Bourne-derived shell I know of, concerning the redirection constructs, >, <, >>, and <<, the name supplied after the redirection operator undergoes variable/command/arithmetic/filename expansion/substitiuon, EXCEPT for the case of <<, the "here document" construct. In this case << name, name does NOT get expanded in any way, and so it is treated like a "label" (ie, like in goto statements.) Thus in << **, since no filename expansion occurs, this is just telling the shell to send the following text to the standard input of the command, until a line containing only ** is reached.
But you could use > * (or > $MYFILE), and this will undergo filename (or variable) expansion, so that output will be redirected to the non-hidden file in the current working directory. (If more than one filename would result from filename expansion in a redirection statement like this, different shells will do different things --- read your shell's docs. E.g., bash will throw an arror and not do anything at all. pdksh will treat the glob pattern as a literal text if it matches more than one file (i.e., creates a file with * or ? in its name); otherwise if only one file matches, it will do filename expansion as expected. Both shells will treat the pattern as literal text if does not match any file at all. But for all shells, at least globbing will be attempted, and if one file matches, redirection will occur as expected.)
ALSO: An important point about here documents: The lines in the here doc (ie, those after the line with << name) are NOT treated as literal text, except if name is quoted in some way. If unquoted, the here-doc text is treated essentially like double quoted text on the command line, i.e., undergoes variable/command/arithmetic expansion/substitution (but not filename/tilde/brace expansion). So if, e.g., you want to feed a literal '$USER' to the command, and not the value of this variable, use:
mycomm << 'EOF' (or "EOF"), and not simply mycomm <<EOF.
(On the other hand, if you do use <<EOF, neither '$USER' nor "$USER" in the here-doc will escape getting expanded, but \$USER will. You can use this last approach if your here doc needs some stuff to get expanded, but other stuff to be escaped.)
So u all mean to say that
/home/adw/a.ksh << **
a
b
only this will not work i'll have to use
/home/adw/a.ksh << **
a
b
**
So here ** is just like any other label
exactly...
the same for
comm <<$VAR_NAME
a
b
$VAR_NAME
You can't end the here doc with the value of this supopsed variable -- it just a label, '$VAR_NAME'