How to identify a shell script?
Tristan Quaife
>
> I wonder if there is a way of easily identify a file whether it is a
> shell script or not?
>
> Regards,
>
> Ricky.
If you have the file command on your system
you can use that to determine the file type:
$ file foo.bash
foo.bash: Bourne shell script text
I think most unix flavours have the file
binary, so you should be in luck.
HTH,
Tristan.
Kevin Miles
>
> I wonder if there is a way of easily identify a file whether it is a
> shell script or not?
>
> Regards,
>
> Ricky.
yes type: file <filename>
You'll get output like this if you typed: file /usr/sbin/dh*
dhcpconfig: executable /usr/bin/ksh script
dhtadm: ELF 32-bit MSB executable SPARC Version 1, dynamically linked,
stripped
--
Kev
Tristan Quaife
>
> Thanks for the prompt reply. However, the "file" command seems to work based
> on the first line of a script. For example, in the following script:
>
> #! /usr/bin/sh
> echo hello
>
> file replied that it is "a /usr/bin/sh script text executable". After I have deleted the first line,
> file replied that it is "a ASCII English text". Is there any work around for this problem?
The file command does indeed rely on the #! magic number in
the first two characters.
The trouble is - how would you tell a script from a normal
ascii text file which just happened to contain some sh style
words?
AFAIK you can't really. You could test for executable status
using:
[ -x $file_name ] && echo this file is executable
but of course you can set executable status to any old file
so it's not really a good test in this case.
Sorry that's not much help is it?
I'll let you know if I have any bright ideas.
Tristan.
Ron DuFresne
Point is though, if the file is mode x, and text, chances are it is a
'script' for a shell, the true issue is determining for which shell it is
ment to run under.
Of course, most everything that can be commandline driven runs under some
kind of 'shell', yes?
Laterer,
Ron DuFresne
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity. It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
***testing, only testing, and damn good at it too!***
OK, so you're a Ph.D. Just don't touch anything.
Tristan Quaife
>
> Tristan Quaife <ggqu...@swansea.ac.uk> wrote:
> : Ricky Tang wrote:
> :>
> :> Thanks for the prompt reply. However, the "file" command seems to work based
> :> on the first line of a script. For example, in the following script:
> :>
> :> #! /usr/bin/sh
> :> echo hello
> :>
> :> file replied that it is "a /usr/bin/sh script text executable". After I have deleted the first line,
> :> file replied that it is "a ASCII English text". Is there any work around for this problem?
>
> : The file command does indeed rely on the #! magic number in
> : the first two characters.
>
> : The trouble is - how would you tell a script from a normal
> : ascii text file which just happened to contain some sh style
> : words?
>
> : AFAIK you can't really. You could test for executable status
> : using:
>
> : [ -x $file_name ] && echo this file is executable
>
> : but of course you can set executable status to any old file
> : so it's not really a good test in this case.
>
> Point is though, if the file is mode x, and text, chances are it is a
> 'script' for a shell, the true issue is determining for which shell it is
> ment to run under.
No, that is not the issue. The OP said:
"I wonder if there is a way of easily identify a file whether it is a
shell script or not?"
Which is the question I was responding to, and why I suggested testing
for [ -x $f ]. But just because the "chances are" that an ascii file with
executable permissions is a shell script, does not make a reliable test.
> Of course, most everything that can be commandline driven runs under some
> kind of 'shell', yes?
Just because something runs 'under' a shell does not make it a shell script.
Tristan.
Dale DePriest
top of their scripts. By the way you should use #! /bin/sh for bourne
shell scripts for portability.
#! tells unix which shell or executable this script is for. Without it
you have a large chance for failure since it may not work.
Dale
Ricky Tang wrote:
>
> Thanks for the prompt reply. However, the "file" command seems to
> work based
> on the first line of a script. For example, in the following script:
>
> #! /usr/bin/sh
> echo hello
>
> file replied that it is "a /usr/bin/sh script text executable". After
> I have deleted the first line,
> file replied that it is "a ASCII English text". Is there any work
> around for this problem?
>
> Regards,
>
> Ricky.
> ----------------------------------------------------------------------
--
For GPS data see: Joe -- http://joe.mehaffey.com
Peter -- http://www.vancouver-webpages.com/peter/
Karen -- http://www.gpsy.com/gpsinfo/
Dale -- http://users.cwnet.com/dalede
Barry Margolin
Tristan Quaife <ggqu...@swansea.ac.uk> wrote:
>No, that is not the issue. The OP said:
>
>"I wonder if there is a way of easily identify a file whether it is a
>shell script or not?"
>
>Which is the question I was responding to, and why I suggested testing
>for [ -x $f ]. But just because the "chances are" that an ascii file with
>executable permissions is a shell script, does not make a reliable test.
Well, since he only asked for an easy way, not a reliable way, I suppose
that fits the bill. :)
However, I've often encountered directories where someone has apparently
done "chmod +x *" so that lots of plain text files have execute
permissions.
--
Barry Margolin, bar...@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Dan Mercer
Dale DePriest <Dal...@cwnet.com> writes:
> The best work around is to fire anyone who does not put the #! at the
> top of their scripts. By the way you should use #! /bin/sh for bourne
> shell scripts for portability.
/bin/sh is unlikely to be a bourne shell in this day and age. It may be
bash1, bash2, a ksh actings as sh, or a posix sh or even ash. As a
portability target, it is very difficult to shoot for without sacrificing
a great deal of functionality. It is far easier to code for ksh -
with the exception of "somecmd | read", there are no great differences
between ksh and pdksh. And "somecmd | read" is easy to program around
with co-processes.
Now, there is good reason for NOT putting "#!/bin/ksh" as the first
line and perhaps putting ":" instead (to prevent csh users from
misfortune): and that is when you want to run the script in a
subshell instead of a shell. Specifying "#!/bin/ksh" causes the
calling shell to fork and exec a new copy of the ksh. Without it,
all it does is fork. That allows you to pass exported arrays, functions
and aliases (ksh93 only passes exported arrays). So there are occasions,
however rare, where leaving of the hashbang is justified.
--
Dan Mercer
dame...@mmm.com
Opinions expressed herein are my own and may not represent those of my employer.