I've got a Node.js command line interface that I'd like to use by default when booting up this Linux system, which is using Upstart (RHEL).
Right now I'm trying to replace the default TTY, mingetty, with my own script, I just haven't had any luck.
I've added my own .conf script to /etc/init that runs the script, but when I override the tty.conf and the serial.conf, I get an empty shell, it never displays my script's output.
What am I missing?
The utility openvt is used for exactly this. For example, copy /etc/init/start-ttys.conf into a /etc/init/start-ttys.override as Upstart likes you to do when editing its init files, and replace the line that calls mingetty with a line that asks openvt to run your utility.
Related
I want to run series of commands in bash shell file. But one of the command requires reboot of the system and I have added reboot command in the shell file. But after the reboot that process is lost. Is there any solution for this?
In the system the only thing that is really persistent is a file. That's pretty much what you should use.
Try making the part of the script that needs to be executed after reboot in to /etc/rc.local from within the script.
Reference
When beginning to work, I have to run several commands:
source work/tools
cd work/tool
source tool
setup_tool
Off course, doing this a few times a day is really annonying, so I tried to make a bash script tool where I put these commands and put it in /user/bin to run it with command
tool
However, there is a problem. When i run the script and then try to work by typing some of the tool-based commands, it does not work.
I figured out, that it is fine, since if I make a script and then run it, the script seems to run in the same terminal window, but what it really does is, that it behaves as if it created a "hidden window" for its execution and after termination of the script, the "hidden window" terminates too. So I am asking - is there a way to automatize the source command?
I have tried using xterm -hold -e command, but it runs the programmed script in the new window. Obviously, I don't want that. How can I achieve running it in the current window?
Don't put files like that in /usr/bin. As a general rule you don't want to mess with the distribution owned locations like that. You can use /usr/local/bin if you need a system-wide location or you can create a directory in your home directory to hold things like this that are for your own usage (and add that to the $PATH).
What you've noticed is that when run as a script on its own (tool, /path/to/tool, etc.) that the script runs in its own shell session (nothing to do with terminal windows as-such) and you don't want that (as the changes the script makes don't persist to your current shell session).
What you want to do instead is "source"/run the script in your current session. Which you are already doing with that set of commands you listed (source work/tools is doing exactly that).
So instead of running tool or /path/to/tool instead use source /path/to/tool or . /path/to/tool.
As fedorqui correctly points out you don't even need a script for this anywhere as you can just make a shell function for this instead (in your normal shell startup files .bashrc, etc.) and then just run that function when you need to so that setup.
Be careful to use full paths for things when you do this though since you, presumably, want this to work no matter what directory you happen to be in when you run it.
It doesn't create a new hidden window, nor does it create a terminal. What happens is that if you're running a script, normally it runs on a new shell process. The script you're running is supposed to modify the shell environment, but if you're running the script in a new shell process, that shell process's environment is the one that gets modified, instead of your shell environment.
Scripts that needs to modify the current shell environments usually must be run with the source command. What you need to do is to run the script in the current shell. So you should do source /path/to/tool.
If you want to be able to source the script with just tool, put this in your alias file/shell startup (check your distro doc where the file is, but it's usually either .bash_aliases or .bashrc):
alias tool="source /path/to/tool"
When I try to run a Perl script which is called via Linux script manually it works fine but not executable via CRON.
Linux_scrip.sh conatains Perl_script and the command is,
perl_path/perl Perl_script.pl
I got perl_path using which perl command.
Can anyone suggest why is it not executable via CRON entry.
Most likely suspects:
Current work directory isn't as expected.
Permission issues[1].
Environment variables aren't setup as expected.
Requirement of a terminal can't be met.
See the crontab tag wiki for more pitfalls and some debugging tips.
The first thing you should do is to read the error message.
This isn't likely to be an issue for you own cron job, but I've included it since it's quite a common problem for scripts run from other services.
Most probable cause is current working directory.
Before perl command execution, write a command to change directory.
Something like :
cd perl_path;
perl Perl_script.pl
I created executables of a python script (via pyinstaller) for Mac, Windows and Linux. For Linux and Mac, I am running them in the shell since it doesn't have an own interface: just open a shell and type the name of the program.
I am wondering if there is a way to use certain file ending so if the user clicks on the program, it will be automatically executed in the shell or terminal. Alternatively, I would appreciate any other ideas of how to do this.
The way to do this is not to append a certain file ending, but, as pointed out in the comment, make the file executable (chmod +x <file>) and add the magic bytes to the beginning of the file that tell the system how to execute it.
The magic bytes are #! and are followed by the path to executable. So for a python script you would put something like the following at the top of the file:
#!/usr/bin/env python
Okay, now I finally found out the solution to my question. All you have to do to execute the program upon clicking on it in the file browser is to add the ending .command and make it executable
E.g., exampleprogram.command. Clicking on it will execute the program in the shell
On Windows, the following registry setting configures the script interpreter to be used by Apache:
HKEY_CLASSES_ROOT\.cgi\Shell\ExecCGI\Command=C:\Perl\bin\perl.exe
How is this done on Linux?
To add a bit more information to #Mohit's good answer:
Unix uses many interpreters for many languages. Some of them are called "shells", but most are just another computer language to the system. In fact, every file is written in some language, even if it's compiled assembly of Java bytecodes.
The first few bytes of a file are "magic": they tell the OS how to execute the file. If the first two bytes are '#!', the OS knows that the file needs an interpreter. The rest of the first line up to newline is then used as a command to execute. The first "word" (space-separated group of non-spaces) of the line is interpreted as absolute file name to run, and all the other words are passed to it as command line arguments. Last parameter is the file name of the file you're running.
So, for example, if you have the first line as
#!/bin/tclsh
in a file /home/user/aaa.tcl
the OS will execute /bin/tclsh with /home/user/aaa.tcl as command line argument:
/bin/tclsh /home/user/aaa.tcl
For a more advanced example, try this:
#! /bin/env perl
in /home/user/myperlscript
This executes the following command:
/bin/env perl /home/user/myperlscript
/bin/env is a utility program that looks up its first argument using PATH environment variable, and then executes the program it finds, passing the rest of its arguments on to the program. With the help of env, you can use PATH to find your interpreters.
If you are talking about CGI script handlers.
It is set on the first line of each CGI script, I frequently use TCL as my script handler in Apache and hence add:
#!/bin/tclsh
Add this line on top of your script, eg. test.cgi and it will be executed by TCL shell whenever it is requested by someone.
Similary you can set it as
for BASH -- #!/bin/sh
or
for PERL -- #!/usr/bin/perl
Note: The path for the shell binary executable can be different, from above, on your machine. Use the following command to find it:
#which perl
Also, as Max has suggested, do check if Apache is configured to allow CGI scripts
Find detailed description of the same here at this Apache Tutorial Link
ScriptInterpreterSource is an Apache configuration setting and is only supported on Windows. I'm not really experienced at configuring Apache on Linux but I reckon you should check out the Script directive.
There is no registry under Linux. Also, I doubt you will get Perl.exe running under Linux.