How do I clear SHELL history in TCSH upon exiting SHELL?
I tried to put history -c in .logout but it didn't work.
Please advice.
Thank you.
PA
Instead of clearing the history, not saving it would be a better option.
You can set the number of lines saved in the savehist variable or set the histfile to /dev/null or something.
End the session with
kill -9 $$
Related
How can I print executed commands in fish shell?
I've tried solutions from In a shell script: echo shell commands as they are executed, but they are not compatible with fish shell.
Starting from fish-3.1.0, $fish_trace can be set to enable output similar to Bash’s set -x.
For example,
set fish_trace 1
before commands that should be traced.
Unfortunately fish doesn't yet have an analog of set -x to print commands. This is the issue requesting it. If you have ideas for what the syntax and output should be, please share them :)
The best answer today is, if you are trying to debug a problem you can invoke fish as fish -d 3 and it will show some debugging output as it runs.
I wrote a simple script
#!/bin/bash
nohup $1 &
exit
what it is supposed to do is if I execute 'scriptName' gedit, it must open gedit and then close the terminal. But, problem is terminal is not closed after the script is executed.
Things taken care of:
Checked terminal preferences to When command exits: Exit the terminal
I want to put this script in /usr/local/bin so, I cannot use execution like . ./scriptname
It appears like terminal is not the parent of this. How do I change this?
The approach you're trying won't work for the following reason:
The shell for your terminal session is one process; normally when you execute a shell script, the terminal session shell starts a second shell process and runs the script under that. So your exit at the end of the script tells the second shell to terminate - which it would do anyway, as it's reached the end of the script. While you could try killing the first shell process from the second shell process (see comment about $PPID in the other answer), this wouldn't be very good form.
For your script to work the way you expect it to work, you'll need to get your terminal session shell to run the commands in your script by using bash's builtin source command - type source /path/to/your/script gedit, or . /path/to/your/script gedit for short.
Because of the way you'd need to execute this, putting the script on your PATH wouldn't help - but you could create an alias (a "shortcut" that expands to a series of shell commands) to make running the script easier - add a line like alias your_alias_name='. /path/to/your/script' to your ~/.bashrc.
Given below the sample script.
#!/bin/bash
echo "hi"
/bin/bash/abc.sh &
sleep 2
#sleep is used to pause the execution temporary to see the output.
kill -25 $PPID
Value that pass to kill command determines the behavior. Here you can find the different values.
Kill -25 worked for me to close the terminal and make sure to add "&" at the end of command. :)
I am presuming you are on a Mac - because you mention Preferences. The question is how did you start the script?
If you started the Terminal and then ran "scriptName" from the Terminal, the Terminal won't quit because it is still running your shell. Check the Preferences closely, it says "When the shell exits", not "When the command exits".
I've recently switched to the ksh93 shell. I did this by adding the following two lines to my .profile file
export SHELL=/usr/local/bin/ksh93
exec $SHELL
Since I did that some simple scripts have started misbehaving in a way I don't understand. I narrowed it down to the following simple script called say test.sh
#!/bin/ksh
echo $0 $1
If I type the command test.sh fred I would expect to see the same output test.sh fred. Instead I see test.sh noglob. If I remove the shebang or if I change it to read #!/usr/local/bin/ksh93 then the script works as expected.
Can anyone explain what's going on, or what to do about it? I'm stumped.
I'm using Solaris 5.9 if it makes any difference.
I notice from the comments that your .kshrc has a set noglob. The set command with no options will set the command-line parameters, which is why $1 is "noglob", it should be set -o noglob.
By the way, setting noglob is weird, are you sure you want that?
I suspect (as others have mentioned) that /bin/ksh is Korn shell 88.
There is an important difference between ksh88 and ksh93 with regards to .kshrc. On ksh88 .kshrc is executed for every korn shell process, even non-interactive ones (scripts). In ksh93 .kshrc is not executed for shell scripts, only for interactive login shells.
When you do exec $SHELL that is not a login shell, it is better to change your entry in /etc/passwd. By the way, using variable SHELL is a bad idea, since that is set by the login shell.
There's probably an alias on ksh in your system with noglob set as an option, or noglob is being passed as a default parameter by default in your old shell. You should also check what ksh you're really calling (check if there's a link to another shell in from /bin/ksh). ksh --version should give some insight as well.
As a last point, instead of calling the shell directly i'd recommend to use
#!/usr/bin/env ksh
I have sourced a script in bash source somescript.sh. Is it possible to undo this without restarting the terminal? Alternatively, is there a way to "reset" the shell to the settings it gets upon login without restarting?
EDIT: As suggested in one of the answers, my script sets some environment variables. Is there a way to reset to the default login environment?
It is typically sufficient to simply re-exec a shell:
$ exec bash
This is not guaranteed to undo anything (sourcing the script may remove files, or execute any arbitrary command), but if your setup scripts are well written you will get a relatively clean environment. You can also try:
$ su - $(whoami)
Note that both of these solutions assume that you are talking about resetting your current shell, and not your terminal as (mis?)stated in the question. If you want to reset the terminal, try
$ reset
No. Sourcing a script executes the commands contained therein. There is no guarantee that the script doesn't do things that can't be undone (like remove files or whatever).
If the script only sets some variables and/or runs some harmless commands, then you can "undo" its action by unsetting the same variables, but even then the script might have replaced variables that already had values before with new ones, and to undo it you'd have to remember what the old values were.
If you source a script that sets some variables for your environment but you want this to be undoable, I suggest you start a new (sub)shell first and source the script in the subshell. Then to reset the environment to what it was before, just exit the subshell.
The best option seems to be to use unset to unset the environment variables that sourcing produces. Adding OLD_PATH=$PATH; export OLD_PATH to the .bashrc profile saves a backup of the login path in case one needs to revert the $PATH.
Not the most elegant solution, but this appears to do what you want:
exec $SHELL -l
My favorite approach for this would be to use a subshell within () parantheses
#!/bin/bash
(
source some_script.sh
#do something
)
# the environment before starting previous subshell should be restored here
# ...
(
source other_script.sh
#do something else
)
# the environment before starting previous subshell should be restored here
see also
https://unix.stackexchange.com/questions/138463/do-parentheses-really-put-the-command-in-a-subshell
I don't think undo of executed commands is possible in bash. You can try tset, reset for terminal initialization.
Depending what you're sourcing, you can make this script source/unsource itself.
#!/bin/bash
if [ "$IS_SOURCED" == true ] ; then
unset -f foo
export IS_SOURCED==false
else
foo () { echo bar ; }
export IS_SOURCED==true
fi
I use multiple bash sessions, and I want to keep track of history from all of them in one file (I don't care that it is multiplexed from multiple sessions, I can always put a session identifier in front of it.) I have tried doing
shopt -s histappend
and also adding
history -a
to the $PROMPT_COMMAND variable. But none of them really work for me, and I don't understand why they don't work (they behave very non-deterministically as far as I can tell... sometimes they multiplex commands from multiple sessions, sometimes they don't).
The goal of this question is to explore an alternate way to keep history from all sessions, where I can control what I write to the history. The idea is to store "previous command" in a shell variable and then echo that variable to a history-log file inside the definition of PS1 variable.
The question is: How do I get the "previous executed command" in a shell variable. I know I can execute echo !! >> logfile.txt in interactive bash session to record it to a log file. But how do I do this in a script file (or .bashrc file)?
I have tried
PROMPT_COMMAND="PC=$_;"
PREVIOUS_COMMAND=$(echo $PC) # $_ only gives the last argument of previous command
export PS1="[\u#\h \w] [$PREVIOUS_COMMAND $(echo $_) $_] $ "
But none of this works.
Thanks for your time,
~yogi
Something like
fc -ln -1
should work. That said, you're probably running into concurrent access issues (read: multiple shells overwriting each others' history) and you may not be able to do any better by hand.