I want the following script command to be executed automatically when ever I log in to shell.
script /home/user/mylog_$(date '+%Y%m%d').log
I forget to run this command most of the times :)
Every time you start an interactive login bash shell, it will execute all commands put in ~/.bash_profile
It depends on the particular shell that you are using.
For bash, add the line to ~/.bashrc.
Related
I've found a very strange issue, when in linux terminal I type "enable -n trap", it would disable the trap linux builtin command. But if I put it into a script like
#!/bin/bash
enable -n trap
and then run the script, there's no error but the command is also not disabled. Really appreciate if someone could share what is happening and how to run it in some file instead of directly in the terminal. Thank you!
The enable command only affects the current shell. When you run a script, that script is executed in a new process, so:
A new shell starts
The enable command runs and disables the trap command in that shell
The shell exits
If you want to affect the current shell, your only option is to source the script using the . (or source) command. If the script is named disable-trap.sh and is in your $PATH, you can run:
. disable-trap.sh
You can also provide a full path to the script:
. /path/to/disable-trap.sh
Sourcing a script like this is largely equivalent to typing the same commands in at the command line: it executes the instructions in the script in the current shell, rather than spawning a new process.
If I start ksh manually by typing
/usr/bin/ksh
in bash, then ksh starts in interactive mode. So far so good. But, since it isn't a login shell, it won't execute its $HOME/.profile, which I need it to do. I tried running
/usr/bin/ksh $HOME/.profile
but then it just executed .profile and exited back to bash, without going into interactive mode. I've tried using the -i flag to force ksh to go into interactive mode, but it doesn't seem to work when I also give it .profile to execute.
I am using ksh93 on Raspian Linux.
When you want the settings in .profile (or any other shellscript), make sure the file is processed in the current shell, not a subshell. Start the commandline with a dot.
. $HOME/.profile
This is not a login shell, just an environment with your .profile executed.
You can use $HOME/.kshrc just like .bashrc for Bash.
What does this command do?
exec bash -l
I found this command as part of a reminder text file were I wrote some instructions regarding how to create a ssh key and clone a git repo, but I wrote it a long time ago and I can't remember what it does.
exec executes a specified command, replacing the current process rather than starting a new subprocess.
If you type
bash -l
at a shell prompt, it will invoke a new shell process (the -l makes it a login shell). If you exit that shell process, you'll be back to your original shell process.
Typing
exec bash -l
means that the new shell process replaces your current shell process. It's probably slightly less resource intensive.
The reason for doing it is probably so that the new shell sets up its environment (by reading your .bashrc, .bash_profile, etc.).
See the bash documentation for more information:
Bash Startup Files for how a login shell differs from a non-login shell
Bourne Shell Builtins for documentation on the exec command.
(You should be able to read the manual on your own system by typing info bash.)
This will replace your current shell with a new bash shell run as a login shell.
I'm trying to get the command history inside a shell script. It doesn't work unless I take out the #!/bin/bash
Any clues on how I can get it to work, or to achieve the same effect without removing #!/bin/bash?
Anyone know why it works to remove #!/bin/bash?
When you take out the shebang line it's being run by your current shell. Bash won't have any history to report unless you're using an "interactive" shell. Try changing your shebang line to:
#!/bin/bash -i
which will cause bash to start an interactive shell.
I'm trying to interactively test code before I put it into a script and was wondering if there are any things that behave differently in a script?
When you execute a script it has its own environment variables which are inherited from the parent process (the shell from which you executed the command). Only exported variables will be visible to the child script.
More information:
http://en.wikipedia.org/wiki/Environment_variable
http://www.kingcomputerservices.com/unix_101/understanding_unix_shells_and_environment_variables.htm
By the way, if you want your script to run in the same environment as the shell it is executed in, you can do it with the point command:
. script.sh
This will avoid creating a new process for you shell script.
A script runs in exactly the same way as if you typed the content in at a shell prompt. Even loops and if statements can be typed in at the shell prompt. The shell will keep asking for more until it has a complete statement to execute.
As David rightly pointed out, watch out for environment variables.
Depending on how you intend to launch your script, variables set in .profile and .bashrc may not be available. This is subject to whether the script is launched in interactive mode and whether it was a login shell. See Quick Startup File Reference.
A common problem I see is scripts that work when run from the shell but fail when run from another application (cron, nagios, buildbot, etc.) because $PATH was not set.
To test if a command/script would work in a clean session, you can login using:
ssh -t localhost "/bin/bash --noprofile --norc"
This ensures that we don't inherit any exported variables from the parent shell, and nothing from .profile or .rc.
If it works in a clean session and none of you're commands expect to be in interactive mode, then you're good to go!