My Mac OS command line application is making Unix calls such as:
system("rm -rf /Users/stu/Developer/file);
perfectly successfully.
So why is the following not changing the current directory?
system("cd /Users/me/whatever");
system("pwd"); //cd has not changed
Because
system() executes a command specified in command by calling /bin/sh -c command, and returns after the command has been completed.
So each command is executed independently, each in a new instance of the shell.
So your first call spawns a new sh (with your current working directory), changes directories, and then exits. Then the second call spawns a new sh (again in your CWD).
See the man page for system().
The better solution is to not use system. It has some inherent flaws that can leave you open to security vulnerabilities. Instead of executing system() commands, you should use the equivalent POSIX C functions. Everything that you can do from the command-line, you can do with C functions (how do you think those utilities work?)
Instead of system("rm -rf ...") use this.
Instead of system("cd ...") use chdir().
Instead of system("pwd ...") use getcwd().
There are some differences, of course, but these are the fundamental equivalents of what you're trying to do.
Related
I am trying to learn shell on Linux,
but I've got a problem which seems confusing.
My environment is:
OS: Manjaro 21.2.6 Qonos
Kernel: x86_64 Linux 5.15.38-1-MANJARO
Shell: zsh 5.8.1 (x86_64-pc-linux-gnu)
The problem is:
I created a file named foo, and echoed #\!/bin/sh to it, and the permission of file foo has been modified to 100 by using chmod.
The file foo doesn't have the read or write permission indeed, that's for true,
but when I executed the command ./foo, I got the error /bin/sh: ./foo: permission denied.
So why the Shell knows what the shebang in the file foo is without the read permission ???
If anyone of you can proide any suggesstions, I will be really thankful !
behavior-example
So why the Shell knows what the shebang in the file foo is without the read permission ???
It is not the shell that reads the shebang line but the OS/kernel.
A shell script can be executed in the same way as a compiled program. The process uses a function of the exec* family and passes ./foo as the program to execute. These functions are based on system calls.
The OS/kernel then detects if the file is a compiled program which can be executed directly or a script file which must be passed to an interpreter. If the file contains a shebang line, the OS will execute the specified interpreter, which does not have to be a shell, otherwise it will run the default shell. The script file is passed as an argument to the interpreter.
The shell is running with normal user permissions and will get an error when it tries to open the script file.
You can find some information about executiong scripts in the POSIX specification of the exec function family or in the Linux manual page for execve. Search for the word interpreter. You could check the Linux kernel source code for more details.
You get this error because the script itself do not have execution or read permission. To run script in shell (on your way) you need to have read and execute permissions:
chmod 500 foo
./foo
the other way to run the script is:
sh foo
and you do not need execution permission in this case. For the record the standard way is to use construction like:
#!/bin/sh
You do not need to escape exclamation mark
I am using Ubuntu via WSL 2.0 on Windows 10 and would like to run Texlive from the Windows command line. To do so I prepended the Texlive folder to the path in /etc/environment (I also tried a number of other locations eg. $HOME/.bashrc):
C:\Users\scott\Documents>wsl echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Windows/system32:...
C:\Users\scott\Documents>wsl
scott#SCOTT-PC:/mnt/c/Users/scott/Documents$ echo $PATH
/usr/local/texlive/2020/bin/x86_64-linux:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Windows/system32:...
Why is there a difference between these two paths? Is it possible to change the first PATH variable?
To be honest, when I first looked at this question, I thought it would be an easy answer. Oh how wrong I was. There are a lot of nuances to how this works.
Let's start with the fairly "easy" part, though. The main difference between the first method and the second:
wsl by itself launches into a login (and interactive) shell
the shell launched with wsl echo $PATH is neither a login shell nor an interactive shell
So the first will source both login scripts (e.g. ~/.profile) and interactive startup scripts (e.g. ~/.bashrc). The second form does not get to source either of these.
You can see this a different way (and get to the solution) with the following commands:
wsl -e bash -c 'echo $PATH'
wsl -e bash -li -c 'echo $PATH'
The -li forces bash to run as a login and interactive shell, thus sourcing all of the applicable startup scripts. And, as #bovquier points out in the comments, a single quote is needed here to prevent PowerShell from interpolating the $ before it gets to Bash. That, or escape it.
You should be able to run TeX Live the same way, just replacing the "echo $PATH" with the startup command you need for TeX Live.
A second option would be to create a script that both adds the path and runs the command, and just launch that script through wsl /path/to/script.sh
That said, I honestly don't think that your current login/interactive PATH is coming from /etc/environment. In my testing, at least, /etc/environment has no use in WSL, and that's to be expected. /etc/environment is only sourced by PAM modules, and with no login check performed by WSL, there's no reason to invoke PAM in either the wsl nor the wsl echo $PATH commands.
I'd expect that you still have the PATH setting in ~/.bashrc or somewhere similar), and that's where the shell is picking it up from at the moment.
While this isn't necessarily critical to understanding the answer, you might also wonder, if /etc/environment isn't used for setting the default (non-login, non-interactive) path in WSL, what is? The answer seems to be that it is hard-coded into the init that starts up WSL. That init is also what appends the Windows path (assuming you don't have that feature disabled in /etc/wsl.conf).
I have multiple scripts naming R001.r, R002.r, and so on. I need to schedule them so that they run in a sequential manner one after the other. What would be the best approach to do this.
I think you want to wrap your r scripts in a caller sh file and then invoke it through terminal. Here is what I would do.
Open up a terminal or any text editor available and fill it up with the following commands:
Rscript R0001.r
Rscript R0002.r
Rscript R0003.r
...
Save this file into something like call_my_scripts. You can then execute it via standard unix shell commands as follows:
./call_my_scripts
This will run sequentially by definition. Make sure you give exec permissions to the file before you invoke it as follows:
chmod u+x call_my_scripts
I am executing a ksh script named abs.ksh located at /app/fao.... which connects to a server,
But the server is receiving a script named "ksh" which is present in /usr/bin...
I am not calling any script called ksh in abs.ksh(sorry cannot paste the code).
Also this happens only when the script is run in debug mode.
In non debug mode it works fine.
Can anyone give me a hint of what might be happening here.
In a standard "classic" Unix environment there may be multiple shells. E.g. 'sh' the original Bourne shell, 'ksh' - the Korn shell, csh - the C shell, bash, tcsh etc. etc.. A user login will have the default shell set per login.
The #! at the start of an executable script is an instruction to interpret & run the subsequent text with the name of the program following the '#!'.
E.g. run this with perl
#!/bin/perl
<.. perl stuff ..>
So yes #!/usr/bin/ksh - will run the script with the command interpreter (shell) at that location.
Need more info. wrt how you run in debug mode. I.e. are you typing 'ksh -x ...' or 'sh -x' - if so where is that on your search path. E.g. 'whence ksh' - maybe you're running with a different shell in debug mode.
Also which os is this ?
I'm trying to call a script in Tcl with the command:
exec source <script path>
and I get the error
couldn't execute "source": no such file or directory
How can I call another script from tcl?
Edit: I am running a command I got from another person in my office. I was instructed to run "source " explicitly with source. So in other words, how would I run any command that would work in cshell, in Tcl?
If the script you were given is a cshell script, you can exec it like this:
exec /bin/csh $path_to_script
In effect, this is what the 'source' command does from within an interactive shell. It's not clear whether this is really what you want to do or not (not exactly, but close enough for this discussion).
The reason you can't exec the source command is that exec will only work on executable files (hence the name 'exec'). The source command isn't implemented as an exectuable file, it is a command built-in to the shell. Thus, it can't be exec'd.
If you really feel the need to exec the source command or any other built-in command you can do something like this:
exec /bin/csh -c "source $path_to_script"
In the above example you are execing the c shell, and asking it to run the command "source ". For the specific case of the source command, this doesn't really make much sense.
However, I'm not sure any of this will really do what you expect. Usually if someone says "here's some commands, just do 'source ', it usually just defines some aliases and whatnot to be used from within an interactive shell. Those aliases won't work from within Tcl.
source in csh, like . in bash, executes a script without spawning a new process.
The effect is that any variable that is set in that script is available in current csh session.
Actually, source is a built-in command of csh, thus not available from tcl exec, and using exec without source would not give the specific source effect.
There is no simple way to solve your problem.
source load the source file
you should do:
source <script path>
If you want to execute it, then you need to call the main proc.
another option would be to do:
exec [info nameofexecutable] <scritp path>
Some confusion here. exec runs a separate program, possibly with arguments.
source is not a separate program, it is another Tcl command which reads a file of Tcl commands and executes them, but does not pass arguments. If the other script you are trying to call is written to be run on from the command line, it will expect to find its arguments as a list in variable argv. You can fake this by setting argv to the list of arguments before running source, eg.
set argv {first_arg second_arg}
source script_path
Alternatively you could use exec to start a whole separate Tcl executable and pass it the script and arguments:
exec script_path first_arg second_arg
the error speaks for itself. Make sure you give the correct path name, specify full path if necessary. and make sure there is indeed the file exists in that directory
Recently I wanted to set some UNIX environment variables by sourcing a shell script and stumbled across the same problem. I found this simple solution that works perfectly for me:
Just use a little 3-line wrapper script that executes the source command in a UNIX shell before your Tcl script is started.
Example:
#!/bin/csh
source SetMyEnvironment.csh
tclsh MyScript.tcl