I am wondering that how can I Use the file command and determine if a file is a script or not.for example in usr bin I want to know which file is script or not. actually i don't want write any script just i need a command for determine that.
You can certainly trust file to find any script in the directory you specify:
file /usr/bin/* | grep script
Or, if you prefer to do it yourself and you are using bash you can do:
for f in /usr/bin/*; do r=$(head -1 $f | grep '^#! */') && echo "$f: $r"; done
which uses the shebang to determine the interpreter and thus the script entity.
This should work (assuming that you're using BASH):
for f in `ls`; do file $f|grep "executable"; done
Update- I just validated that this works for C shell scripts, BASH, Perl, and Ruby. It also ignores file permissions (meaning that even if a file doesn't have the executable bit set, it still works). This seems to be do to the file command looking for a command interpreter (bash, perl, etc…)
file can't guarantee to tell you anything about a text file, if it doesn't know how to interpret it.
You may need to do a combination of things. jschorr's answer should probably work for the stuff in /bin, but another way to test a file might be to check whether a text file is executable.
stat -c "%A" myfilename | grep x
If that returns anything, then your file has execute permissions on it. So if file gets you a description that tells you it's plain text (like "ASCII text"), and there are execute permissions on the file, then it's a pretty good bet that it's a script file.
Not perfect, but I don't think anything will be.
Related
I am trying to run script on output files that can be further used as input files for gaussian.
I wanted to know what are the commands used in Linux to run the script on .log files and .HSCP1 files.
Many thanks,
Regards,
The generic syntax of passing an argument to a script in linux, assuming your script is named script.sh and your target file is named arg.log, would be
script.sh arg.log
This assigns the name arg.log to $1 inside the environment of the executing copy of script.sh. If you don't then do something with that, it won't matter.
You might also have your script read its stdin like this:
script.sh < arg.log
which will put the contents os arg.log on script.sh's stdin, but unless it reads them accordingly, it won't matter.
Of course, both these assume script.sh is in your $PATH; otherwise you will need to apply a path for the OS, such as /path/to/dir/with/script.sh or (if you are in the same directory) ./script.sh.
If what you are asking is how to get a lorge number of files assigned as arguments, you could pass wildcards - for the first example above, that could be done as
./script.sh /path/to/*.log /also/to/other.*
or you could use find, maybe with xargs like so -
find /path/to/files/ -name *.log | xargs /path/of/script.sh
which will call the script over and over.
I hope one of these helps, but you really must provide more context for what you are doing and how.
I don't understand the meaning of:
$ ./your_program <dino>wilma
I'm learning perl, and I do not understand how to do this. I am using PUTTY.
The $ ./your_program indicates that you should run a program your_program on your shell. It assumes you have Linux. The $ indicates your command prompt.
So if you have a Windows machine and a server or another computer with Linux that you connect to with PuTTY, you need to write your program on that machine.
Then you need to make it executable.
$ chmod u+x your_program
Now you can run it. Running a program that is executable in Linux is done by typing the name of the program into the shell. You just did that with chmod, and maybe with vim or emacs when you created the file. But because your program is not accessible from everywhere, you need to put the ./your_program so the shell knows that you want to run it inside of the current directory. That's what the . is for.
$ ./your_program wilma
The wilma is a command line argument. It will be passed to your program.
You could also run it with the perl interpreter without making it executable.
$ perl your_program wilma
You can name all your Perl programs with .pl at the end so it's easier for you to distinguish what type of file they are.
$ denotes the unix command prompt.
./ is the current path - by convention unix systems don't look for executable programs in the current working directory (the places it looks is defined by the PATH environment variable).
your_program is the name of the file you just created/saved.
The above will only work if your file is set "executable" - chmod u+x your_program. You can alternatively use perl your_program and achieve basically the same result.
<dino means 'open the file "dino" and feed it into this program on the standard input. (STDIN).
>wilma means open the file "wilma"; truncate it, and write the output of this program to this file.
STDIN is a unix concept that's 'standard input' - it can either be 'things you type' or the content of a file or command.
That might not make a lot of sense, but it's all about piping - you can:
cat file | grep someword | sed 's/oneword/anotherword/'
That opens a file ( with cat) filters all the lines containing someword and then does a pattern replacement on it.
cat will "send" file to grep on STDIN.
It seems to be a quotation from chapter 5.6 of Learn Perl, the whole quote is:
...In that way, the user can type a command like this one at the shell
prompt:
$ ./your_program <dino >wilma
That command tells the shell that the program's input should be read
from the file dino, and the output should go to the file wilma. As
long as the program blindly reads its input from STDIN, processes it
(in whatever way we need), and blindly writes its output to STDOUT,
this will work just fine.
http://perl.find-info.ru/perl/027/learnperl4-chp-5-sect-6.html
Perhaps a Chinese translation might be of use to the OP 文海梅:
http://www.biostatistic.net/thread-4903-1-1.html
I'm pretty new to Bash and Linux in general. I've created a couple scripts that I would like to be able to use by typing the command, rather than the directory and the executable file. I'm using Debian Jessie if that makes a difference.
The path to one of my scripts is ~/Scripts/DIR_1/My_Script.sh while another is in ~Scripts/DIR_2/My_Other_Script.sh. I would like ALL of the scripts contained withing the Scripts directory to be indexed as commands regardless of directory/path depth.
I've appended this text to the end of my .bashrc file...
PATH=${PATH}:$(find ~/Scripts -type d | sed '/\/\\./d' | tr '\n' ':' | sed 's/:$//')
Since I'm pretty new to this kind of thing, I had to steal that line from here.
When I try to run My_Script from the command line withing a sub directory of my home folder (or anywhere else for that matter) I get My_Script: command not found
I will readily admit that I might have misunderstood the process of adding a bash script to the command line.
How do I recursively add bash scripts as commands? What is wrong with the process I'm currently using?
I think your issue is that you're not putting the .sh, that is part of your file name.
Normally, pressing tab after having typed only the first letter should complete the command up to the point where there is an ambiguity (or completely if there's none). In case of ambiguity, pressing tab a second time shows the options. So in your case, if you type My<tab><tab> you should have options My_Script.sh and My_Other_Script.sh displayed. And if you type My_Script<tab> it should complete by putting My_Script.sh
Edit
I forgot to precise that you can check the value of PATH by doing echo $PATH. This will allow you to check that the command you copied did what you wanted.
I am trying to create a script that will run a program on each file in a list. I have been trying to do this using a .csh file (I have no clue if this is the best way), and I started with something as simple as hello world
echo "hello world"
The problem is that I cannot execute this script, or verify that it works correctly. (I was trying to do ./testscript.csh which is obviously wrong). I haven't been able to find anything that really explains how to run C Scripts, and I'm guessing there's a better way to do this too. What do I need to change to get this to work?
You need to mark it as executable; Unix doesn't execute things arbitrarily based on extension.
chmod +x testscript.csh
Also, I strongly recommend using sh or bash instead of csh, or you will soon learn about the idiosyncrasies of csh's looping and control flow constructs (some things only work inside them if done a particular way, in particular with the single-line versions things are very limited).
You can use ./testscript.csh. You will however need to make it executable first:
chmod u+x testscript.csh
Which means set testscript to have execute permissions for the user (who ever the file is owned by - which in this case should be yourself!)
Also to tell the OS that this is a csh script you will need put
#! /path/to/csh
on the first line (where /path/to/csh is the full path to csh on your system. You can find that out by issuing the command which csh).
That should give you the behvaiour you want.
EDIT As discussed in some of the comments, you may want to choose an alternative shell to C Shell (csh). It is not the friendliest one for scripting.
You have several options.
You can run the script from within your current shell. If you're running csh or tcsh, the syntax is source testscript.csh. If you're running sh, bash, ksh, etc., the syntax is . ./testscript.sh. Note that I've changed the file name suffix; source or . runs the commands in the named file in your current shell. If you have any shell-specific syntax, this won't work unless your interactive shell matches the one used by the script. If the script is very simple (just a sequence of simple commands), that might not matter.
You can make the script an executable program. (I'm going to repeat some of what others have already written.) Add a "shebang" as the first line. For a csh script, use #!/bin/csh -f. The -f avoids running commands in your own personal startup scripts (.cshrc et al), which saves time and makes it more likely that others will be able to use it. Or, for a sh script (recommended), used #!/bin/sh (no -f, it has a completely different meaning). In either case, run chmod +x the_script, then ./the_script.
There's a trick I often use when I want to perform some moderately complex action. Say I want to delete some, but not all, files in the current directory, but the criterion can't be expressed conveniently in a single command. I might run ls > tmp.sh, then edit tmp.h with my favorite editor (mine happens to be vim). Then I go through the list of files and delete all the ones that I want to leave alone. Once I've done that, I can replace each file name with a command to remove it; in vim, :%s/.*/rm -f &/. I add a #!/bin/sh at the top save it, chmod +x foo.sh, then ./foo.sh. (If some of the file names might have special characters, I can use :%s/.*/rm -f '&'/.)
I want to write a very simple script , which takes a process name , and return the tail of the last file name which contains the process name.
I wrote something like that :
#!/bin/sh
tail $(ls -t *"$1"*| head -1) -f
My question:
Do I need the first line?
Why isn't ls -t *"$1"*| head -1 | tail -f working?
Is there a better way to do it?
1: The first line is a so called she-bang, read the description here:
In computing, a shebang (also called a
hashbang, hashpling, pound bang, or
crunchbang) refers to the characters
"#!" when they are the first two
characters in an interpreter directive
as the first line of a text file. In a
Unix-like operating system, the
program loader takes the presence of
these two characters as an indication
that the file is a script, and tries
to execute that script using the
interpreter specified by the rest of
the first line in the file
2: tail can't take the filename from the stdin: It can either take the text on the stdin or a file as parameter. See the man page for this.
3: No better solution comes to my mind: Pay attention to filenames containing spaces: This does not work with your current solution, you need to add quotes around the $() block.
$1 contains the first argument, the process name is actually in $0. This however can contain the path, so you should use:
#!/bin/sh
tail $(ls -rt *"`basename $0`"*| head -1) -f
You also have to use ls -rt to get the oldest file first.
You can omit the shebang if you run the script from a shell, in that case the contents will be executed by your current shell instance. In many cases this will cause no problems, but it is still a bad practice.
Following on from #theomega's answer and #Idan's question in the comments, the she-bang is needed, among other things, because some UNIX / Linux systems have more than one command shell.
Each command shell has a different syntax, so the she-bang provides a way to specify which shell should be used to execute the script, even if you don't specify it in your run command by typing (for example)
./myscript.sh
instead of
/bin/sh ./myscript.sh
Note that the she-bang can also be used in scripts written in non-shell languages such as Perl; in the case you'd put
#!/usr/bin/perl
at the top of your script.