I´m currently writing a snakemake pipeline, for which I want to include a perl script.
The script is not written by me, but from a github page. I never worked with perl before.
I installed perl (5.32.1) via conda. I have installed miniconda and am working on my universities unix server.
The code for my perl script rule looks like this:
rule r1_filter5end:
input:
config["arima_mapping"] + "unprocessed_bam/{sample}_R1.sam"
output:
config["arima_mapping"] + "filtered_bam/{sample}_R1.bam"
params:
conda:
"../envs/arima_mapping.yaml"
log:
config["logs"] + "arima_mapping/r1_filter5end/{sample}_R1.log"
threads:
12
shell:
"samtools view --threads {threads} -h {input} -b | perl ../scripts/filter_five_end.pl | samtools -b -o {output} 2> log"
When I run this I receive the following error:
Can't open perl script "../scripts/filter_five_end.pl": no such file
or directory found
From what I learned while researching is that the 1. line of a perl script sets the path to my perl executable. The script I downloaded had the following path:
#!/usr/bin/perl
And since I use perl installed via conda this is probably wrong. So I set the path to:
#!/home/mi/my_user/miniconda3/bin/perl
However this did still not work, regardless of if I call
perl ../scripts/filter_five_end.pl
or
../scripts/filter_five_end.pl
Maybe it´s just not possible to run perl scripts via snakemake?
Anyone who had encountered this specific similar case?^^
The problem is not with the shebang. The interpreter path in the shebang doesn't matter because you're calling it with perl ../path directly. The shell that this command is executed in will resolve the path to the perl program (which is very likely the conda one) and then run the script, only taking flags (like -T or -w) from the shebang inside the script.
The error message means it cannot find the actual script file. I suspect when you run that shell command, it's in the wrong directory. Try a fully qualified path.
As stated by OP in their comment:
I forgot that snakemake always looks files up from the Snakemake file not the directory the rules are saved in.
Not quite an answer but perhaps relevant:
I forgot that snakemake always looks files up from the Snakemake file not the directory the rules are saved in.
This is not entirely correct, I think. The reference point is the directory set by -d/--directory which by default is where you execute snakemake:
--directory DIR, -d DIR
Specify working directory (relative paths in the snakefile will use this as their origin). (default: None)
Related
I am trying to use git bash to run my .sh file that was generated using Makefile.
When running the command ./run.sh I get this message ./run.sh: line 1: /home/user/run: No such file or directory
To run a script file (using Git Bash), you do the following:
Add a "sh-bang" line on the first line (e.g. #!/bin/bash OR #!/usr/bin/env sh) this is how git bash knows a file is executable.
Use ./ (or any valid dir spec): ./script.sh
Note : any "sh-bang" will work
You are using git bash so I suppose you are using Windows.
As for me I always use shebang on my scripts. Depending on the content of your script, you may add one of the following lines at the first line of your script.
#!/bin/sh
#!/bin/bash
#!/usr/bin/perl
#!/usr/bin/tcl
#!/bin/sed
#!/usr/awk
#!/usr/bin/python
If you still have problems running the script with ./run.sh command, you may try to use sh run.sh (on Git bash) and it should execute the script just as ./run.sh does it on linux.
This error message says that the first line of the script tries to execute an executable program named run in your home directory, and this does not exist.
I don't know what run.sh is supposed to do, but if you want to execute it a program, you need to make sure that the program exists, for instance by creating it.
So I was trying to create little .sh script for my work and run into one little problem.
My cygwin terminal (x64) runs just fine and I'm using it often enough to do manual greps.
In the begging I had some issues with this command but now it works fine in cygwin terminal.
Once I wrote my little script and tried to run it only output I'm getting is "line 6: grep: command not found"
My execution method is:
Open cygwin terminal
cd to script location
type in ./script.sh
enter :)
Anyone knows how to fix that? I already added cygwin bin folder to my system path (Win 10 btw) but that didn't helped. Looked around for a while but haven't found anything useful, mostly issues with grep itself.
my script for reference:
mkdir -p output
PATH=$PWD"/output"
while IFS=";" read -r component location global
do
cd $location
grep -iRl $global --exclude-dir={wrongdir1,wrongdir2} > $PATH"/"$component".txt"
done < input.csv
you're overwriting you Cygwin system path: PATH=$PWD"/output" - instead of PATH use a diff var name.
I own the licensed version of Pycharm. I have installed BashSupport plugin as well.
However, I am not sure what steps are required to remotely test and execute a bash script on RHEL server.
I am able to configure a remote interpreter but the interpreter path is /usr/bin/python.
In my logic you need to change interpreter path to /bin/bash instead of /usr/bin/python or i don't understand what you are trying to do..
I've met the save problem today.
If I use the default pycharm bash configuration, I'll get the following error:
C:\windows\system32\bash.exe C:/git/NewProject/run.sh
/bin/bash: C:/git/NewProject/run.sh: No such file or directory
Process finished with exit code 127
So, I change the default Windows Script path to Linux absolute Script path as following:
Run successfully.
You gotta check the path on server, If there is alias set, You can check alias
$ which python
$ whence python (Some version)
$ ls -l `which python`
I have a bash script like:
#!/bin/bash
echo Hello world!
How do I execute this in Terminal?
Yet another way to execute it (this time without setting execute permissions):
bash /path/to/scriptname
$prompt: /path/to/script and hit enter. Note you need to make sure the script has execute permissions.
cd to the directory that contains the script, or put it in a bin folder that is in your $PATH
then type
./scriptname.sh
if in the same directory or
scriptname.sh
if it's in the bin folder.
You could do:
sh scriptname.sh
This is an old thread, but I happened across it and I'm surprised nobody has put up a complete answer yet. So here goes...
The Executing a Command Line Script Tutorial!
Q: How do I execute this in Terminal?
The answer is below, but first ... if you are asking this question, here are a few other tidbits to help you on your way:
Confusions and Conflicts:
The Path
Understanding The Path (added by tripleee for completeness) is important. The "path" sounds like a Zen-like hacker koan or something, but it is simply a list of directories (folders) that are searched automatically when an unknown command is typed in at the command prompt. Some commands, like ls may be built-in's, but most commands are actually separate small programs. (This is where the "Zen of Unix" comes in ... "(i) Make each program do one thing well.")
Extensions
Unlike the old DOS command prompts that a lot of people remember, you do not need an 'extension' (like .sh or .py or anything else), but it helps to keep track of things. It is really only there for humans to use as a reference and most command lines and programs will not care in the least. It won't hurt. If the script name contains an extension, however, you must use it. It is part of the filename.
Changing directories
You do not need to be in any certain directory at all for any reason. But if the directory is not on the path (type echo $PATH to see), then you must include it. If you want to run a script from the current directory, use ./ before it. This ./ thing means 'here in the current directory.'
Typing the program name
You do not need to type out the name of the program that runs the file (BASH or Python or whatever) unless you want to. It won't hurt, but there are a few times when you may get slightly different results.
SUDO
You do not need sudo to do any of this. This command is reserved for running commands as another user or a 'root' (administrator) user. Running scripts with sudo allows much greater danger of screwing things up. So if you don't know the exact reason for using sudo, don't use it. Great post here.
Script location ...
A good place to put your scripts is in your ~/bin folder.
You can get there by typing
# A good place to put your scripts is in your ~/bin folder.
> cd ~/bin # or cd $HOME/bin
> ls -l
You will see a listing with owners and permissions. You will notice that you 'own' all of the files in this directory. You have full control over this directory and nobody else can easily modify it.
If it does not exist, you can create one:
> mkdir -p ~/bin && cd ~/bin
> pwd
/Users/Userxxxx/bin
A: To "execute this script" from the terminal on a Unix/Linux type system, you have to do three things:
1. Tell the system the location of the script. (pick one)
# type the name of the script with the full path
> /path/to/script.sh
# execute the script from the directory it is in
> ./script.sh
# place the script in a directory that is on the PATH
> script.sh
# ... to see the list of directories in the path, use:
> echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# ... or for a list that is easier to read:
> echo -e ${PATH//:/\\n}
# or
> printf "%b" "${PATH//:/\\n}"
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin
2. Tell the system that the script has permission to execute. (pick one)
# set the 'execute' permissions on the script
> chmod +x /path/to/script.sh
# using specific permissions instead
# FYI, this makes these scripts inaccessible by ANYONE but an administrator
> chmod 700 /path/to/script.sh
# set all files in your script directory to execute permissions
> chmod +x ~/bin/*
There is a great discussion of permissions with a cool chart here.
3. Tell the system the type of script. (pick one)
Type the name of the program before the script. (Note: when using this method, the execute(chmod thing above) is not required
> bash /path/to/script.sh
...
> php /path/to/script.php
...
> python3 /path/to/script.py
...
Use a shebang, which I see you have (#!/bin/bash) in your example. If you have that as the first line of your script, the system will use that program to execute the script. No need for typing programs or using extensions.
Use a "portable" shebang. You can also have the system choose the version of the program that is first in the PATH by using #!/usr/bin/env followed by the program name (e.g. #!/usr/bin/env bash or #!/usr/bin/env python3). There are pros and cons as thoroughly discussed here.
Note: This "portable" shebang may not be as portable as it seems. As with anything over 50 years old and steeped in numerous options that never work out quite the way you expect them ... there is a heated debate. The most recent one I saw that is actually quite different from most ideas is the "portable" perl-bang:
#!/bin/sh
exec perl -x "$0" "$#"
#!perl
Firstly you have to make it executable using: chmod +x name_of_your_file_script.
After you made it executable, you can run it using ./same_name_of_your_file_script
Change your directory to where script is located by using cd command
Then type
bash program-name.sh
And yet one more way
. /path/to/script
What is the meaning of the dot?
If you are in a directory or folder where the script file is available then simply change the file permission in executable mode by doing
chmod +x your_filename.sh
After that you will run the script by using the following command.
$ sudo ./your_filename.sh
Above the "." represent the current directory.
Note!
If you are not in the directory where the bash script file is present then you change the directory where the file is located by using
cd Directory_name/write the complete path
command. Otherwise your script can not run.
I'm trying to write (what I thought would be) a simple bash script that will:
run virtualenv to create a new environment at $1
activate the virtual environment
do some more stuff (install django, add django-admin.py to the virtualenv's path, etc.)
Step 1 works quite well, but I can't seem to activate the virtualenv. For those not familiar with virtualenv, it creates an activate file that activates the virtual environment. From the CLI, you run it using source
source $env_name/bin/activate
Where $env_name, obviously, is the name of the dir that the virtual env is installed in.
In my script, after creating the virtual environment, I store the path to the activate script like this:
activate="`pwd`/$ENV_NAME/bin/activate"
But when I call source "$activate", I get this:
/home/clawlor/bin/scripts/djangoenv: 20: source: not found
I know that $activate contains the correct path to the activate script, in fact I even test that a file is there before I call source. But source itself can't seem to find it. I've also tried running all of the steps manually in the CLI, where everything works fine.
In my research I found this script, which is similar to what I want but is also doing a lot of other things that I don't need, like storing all of the virtual environments in a ~/.virtualenv directory (or whatever is in $WORKON_HOME). But it seems to me that he is creating the path to activate, and calling source "$activate" in basically the same way I am.
Here is the script in its entirety:
#!/bin/sh
PYTHON_PATH=~/bin/python-2.6.1/bin/python
if [ $# = 1 ]
then
ENV_NAME="$1"
virtualenv -p $PYTHON_PATH --no-site-packages $ENV_NAME
activate="`pwd`/$ENV_NAME/bin/activate"
if [ ! -f "$activate" ]
then
echo "ERROR: activate not found at $activate"
return 1
fi
source "$activate"
else
echo 'Usage: djangoenv ENV_NAME'
fi
DISCLAIMER: My bash script-fu is pretty weak. I'm fairly comfortable at the CLI, but there may well be some extremely stupid reason this isn't working.
If you're writing a bash script, call it by name:
#!/bin/bash
/bin/sh is not guaranteed to be bash. This caused a ton of broken scripts in Ubuntu some years ago (IIRC).
The source builtin works just fine in bash; but you might as well just use dot like Norman suggested.
In the POSIX standard, which /bin/sh is supposed to respect, the command is . (a single dot), not source. The source command is a csh-ism that has been pulled into bash.
Try
. $env_name/bin/activate
Or if you must have non-POSIX bash-isms in your code, use #!/bin/bash.
In Ubuntu if you execute the script with sh scriptname.sh you get this problem.
Try executing the script with ./scriptname.sh instead.
best to add the full path of the file you intend to source.
eg
source ./.env instead of source .env
or source /var/www/html/site1/.env