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.
Related
Yes. I know I shouldn't be using it for scripting. Yes. It is rubbish. I am indeed a fool.
Nevertheless.
I'd like to see the commands the script is executing, for debugging purposes. I think you get this effect with set -x or set -v in bash scripts.
So e.g., if the script were
#!/bin/tcsh
echo "Hello"
then when it ran, I'd see
echo "Hello"
Hello
Put:
set echo
and/or
set verbose
at the top of your script. That will print out everything that happens in your script and are equivalent to the bash set -x and set -v commands.
Lets say your script name is tcsh_file
Lets assume this file includes shebang as well.
now run this command on terminal
tcsh -x tcsh_file
this will print every line before executing it. it's basically an interactive mode of execution.
Is this what you needed?
In following some random directions on the internet, trying to debug an issue of mine at a shell (I use zsh), I ran set -x. Thanks to this I figured out my issue. However, I'm now in an awkward position of not knowing how to turn this debugging off -- I really don't even understand what I did in the first place, you see.
I also figured out that I could just do zsh and get a new shell. The obvious unset -x does not work. I would like to know the correct way. Thanks!
Update:
Found this unix&linux stack exchange post about what -x does. Still don't know how to turn it off.
You can use set +x to switch it back. The output of help set describes this:
$ help set
set: set [--abefhkmnptuvxBCHP] [-o option] [arg ...]
...
-v Print shell input lines as they are read.
-x Print commands and their arguments as they are executed.
...
Using + rather than - causes these flags to be turned off. The
flags can also be used upon invocation of the shell. The current
set of flags may be found in $-. The remaining n ARGs are positional
parameters and are assigned, in order, to $1, $2, .. $n. If no
ARGs are given, all shell variables are printed.
Note the “Using + rather than - causes these flags to be turned off” part.
I have made a really sincere effort to figure this out, and I just can't. This is my very simple bash script. The lines that begin "export" and "echo" seem to work, so I know my script is executing. If I enter the line that begins "source" at the prompt in the terminal I get a lot of printed output that indicates that the command is running, but if I execute my script, nothing happens (and in fact subsequent efforts to use Freesurfer indicate that it hasn't worked). I have a feeling there may be something very basic I don't get about bash scripting, but I can't figure out what that thing is from looking at tutorials.
#!/bin/bash
export FREESURFER_HOME=/foo/freesurfer
echo "starting freesurfer"
echo $FREESURFER_HOME
source $FREESURFER_HOME/SetUpFreeSurfer.sh
export SUBJECTS_DIR=/bar/my_dir
If you run your script using ./scriptname.sh it is exexuted in a subshell. Every variable that is set there etc cannot change the environment of the parent shell. In order to do so you need to source the script.
See eg. this question on superuser
I'm trying to create a script to to do simple things. I need to prompt the user to reply to a question, typing yes or no. The script is written for csh, but does not work when default user shell is bash. My environment is Red Hat Enterprise Linux 5
#!/bin/csh -f
echo -n Type yes to continue
set answer = $<
#...
This code works fine with csh but not with bash where it prints the following error:
syntax error near unexpected token 'newline'
bash 'set answer =$<'
I really need to have the same script working for both shell (I thought it was the purpose of putting #!/bin/csh at the beginning of the file!)
I don't really know how to modify my script to make it working in bash. Could you help me please? Thanks a lot for your help.
It would be hard to think of two more different shells than csh and bash. They are different languages, you cannot expect csh code to work in bash, or the other way around.
In bash you read from STDIN using the shell builtin read, in csh you use the construct $<. Different languages.
I really need to have the same script working for both shell Why? When you place #!/bin/csh at the start of the script then it will run the c-shell, use #!/bin/bash then it will run bash. Common mistake is to have white-space or some other character before the #!, they must be absolutely the very first two bytes in the file.
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