As a workaround for a problem that I face when deploying code using central version control throughout various sites in the company I work, I need, in all sites, to run Ruby from (say):
#!/foo1/bin/ruby -w
However, in just 1 location, ude to an I.T. issue, which may or may not be resolved, I need to use (say):
#!/foo2/bin/ruby -w
This needs to work for ALL users in ALL sites, and I cannot enforce the setup of environment variables. One can of course, use a bash script to split the 2, (a bash script calling either of the locations), but I was hoping for just 1 process, and 1 script. Any ideas?
There are many options to solve that but the simples that I'm familair with is:
Make sure that ruby is accesible by the PATH environment variable.
Instad of using the full path to ruby you can use the /bin/env command that comes in all Linux bundles:
#!/bin/env ruby
Related
I'm having an issue with WSL2:
$ where b4a
/usr/local/bin/b4a
$ b4a new
/usr/local/bin/b4a: 1: Not: not found
Even though where finds commands, I can't run them. And it's not a PATH issue either:
echo $PATH
/usr/local/sbin:/usr/local/bin:[...]
And b4a isn't the only command with this problem. What could be the cause? My distribution is Debian 10 and host is Windows 10.
Not necessarily a full answer, but hopefully the troubleshooting methods you need to arrive at a solution ...
Note that it doesn't say that the command itself isn't found. For instance, if you run:
# lllllllllll
lllllllllll: command not found
That's truly a command not found. This is different. While I don't (yet) know the exact cause, this seems closer to the issues we might see with improperly quoted paths with spaces in a shell script.
You mention that other commands have this problem -- Is there something in common with the commands that don't work properly? Is it possible that they are all shell scripts?
Try several things to debug:
Start WSL without your startup profile. It's very likely that something (or you) added a line that is causing problems. From PowerShell or CMD:
wsl ~ -e bash --noprofile --norc
b4a
If that works, then there's a problem in one of your startup files that you'll need to debug. Look for anything modifying environment variables without proper quoting, especially the PATH. WSL automatically appends the Windows path to your Linux path to make it easy to run Windows commands, but the fact that almost every Windows path has spaces in it can cause problems for unsuspecting scripters that don't take this corner case into account.
Having a space in a path is fully allowed in Linux, but some scripts just don't handle it properly.
If the command that is failing is a shell script, trying starting it with:
bash -x /usr/local/bin/b4a
Or even start WSL with wsl ~ -e bash -x to see all trace output from the shell.
In this case, you'll be looking for some problem in the script right around where it actually fails.
If all else fails, you can disable WSL's PATH modification via its config file:
sudo -e /etc/wsl.conf
Add the following:
[interop]
appendWindowsPath = false
Then exit Debian, run wsl --shutdown and restart Debian. Try the b4a command again.
If this works, then the problem is almost certainly due to some problem in the PATH quoting in these commands. I don't recommend it as a permanent solution since you will have to type out the full path of Windows applications each time you want to run them.
I have repackaged a Bash RPM to include automatic logging to syslog. I am trying to work out a way to set this up so that it is used ONLY when a user or service account runs a command as root. The option I'm looking at is installing this version of Bash to an alternate location, and then pointing root to use that version as it's default shell.
Can someone go through the process of installing this RPM to an alternate path and associating the root account to it as the default shell? I have been having difficulty finding a way to do this when searching online.
Since you are repackaging the RPM, it is probably best to change the destination path directly in the RPM.
As for the default shell, run chsh -s /path/to/your/bash root to change it.
Be aware that this solution may not work for all purposes though. For example, running a script that starts with #!/bin/bash will still execute it with /bin/bash instead of your default login shell.
I need to script the installation of a number of products on Redhat Linux
I am installing from previously downloaded tar files that each contain their own specific install.sh.
My problem is that by executing the install.sh scripts a number of questions are asked such as ...
a). Accept license
b). set default path(s)
c). do i wish to start service
etc...
Can Bash detect these questions and respond correctly? or do i require another linux based product/function?
For windows based installs i have used AutoItScript.
What are my options on Linux Redhat?
To establish whether the scripts support any command line options, you can:
Read the readme file of the software, if there is one. This should explain any options.
Read the top of the install.sh script. Usually options are at least listed there.
Read the code itself, which might be a lot of work.
Once you have established that the scripts do not support options, the standard way of automating this would be with an expect script. See for example automating install.sh script using an expect script.
Depending on how the install script works, you may be able to send it commands on standard input. For example, if you press Tab once, then Enter, then y and lastly Enter again, you can try the following:
printf %s $'\t\ny\n' | ./install.sh
I have a Perl script which I want to run in Linux. I know about the plugins which we can use, but that's a limitation for me. I will have to use External Tools Configurations to run it. I searched on the internet, but there is no place where i could find the explanation.
I tried using external tools, but when I run it nothing is showing up on my screen. May be I did the wrong way.
The way I filled it was:
Name: I gave any random name
Location: I gave /usr/bin/perl
Working Directory: the path of the directory where my Perl script is located.
Arguments: Name of my Perl script.
I would also like to mention that my script calls an executable file (a C++ makefile) which runs rest of my program. Maybe that is the problem?
I am using Perl perspective. I am not an Eclipse expert, so I might be missing something important. Please advise.
I think the location would be your Perl script.
/usr/bin/perl /path/to/your/script.pl
/path/to/your/script.pl
Check these links, maybe useful:
http://wiki.eclipse.org/FAQ_How_do_I_add_my_own_external_tools%3F
http://help.eclipse.org/helios/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Ftasks%2Ftasks-exttools-running.htm
I have an escript file which runs fine from the command line, i.e.:
./escript_file
It is meant to be cron friendly and all paths are explicit but when I run it, it fails to compile saying that there are bad attributes.
The bad attributes in question are macro definitions:
-define(COOKIE, 'somecookie').
The Answer
Thanks to Geoff Ready's suggestion I investigated which version of Erlang was running by printing out init:script_id() which prints out a string like {"OPT APN 181 O1", "R13B"} and, sure enough the command line and cron versions were picking up different versions.
The script had an initial line:
#!/usr/bin/env escript
and the operating system was 'finding' Erlang for me. The different environment variables of cron meant that a different erlang was being picked up (Geoff's first answer, and one I kinda knew but couldn't see how it would affect things).
The solution is then to force the version with a starting line of:
#!/usr/local/lib/erlang/erts-5.7.3/bin/escript
Postscript
There was also a different Ubuntu apt-get install of an earlier version of Erlang (in a different location to the source install) and an errant 64-bit install...
The cron environment just kept falling back to older and more obscure installs, failing all the while :(
Perhaps cron is picking up a different version of erlang in the path. Erlang R12B documentation says that escript ignores preprocessor directives besides include_lib. Erlang R13B documentation says that the preprocessor is run on the file. That would definitely explain the difference in behavior.
If it is working fine from the command line, a likely cause is a difference in environment variables for your interactive shell versus when cron runs the script.
Changing #!/usr/bin/env escript to #!/usr/local/bin/escript at the top of the file will work if the Erlang versions are the same.