When I tried running my shell script earlier it said end of file error.
But after running the following two commands it started running fine.
export SHELLOPTS
set -o igncr
please explain what is the reason behind this.
set -o igncr causes the shell ignore windows line endings (skip \r). Another solution would be to fix the script by running dos2unix on it.
Please don't use bash -o igncr or set -o igncr in modern cygwin bash >= 3.2.
You can pass global env SHELLOPTS=igncr before executing your script and forget about carriage return issues.
Read more information about igncr absurd in cygwin bash.
Related
So I have this shell script that checks and then concats an environmental variable to /etc/environment, then reloads the file without having to logout/login:
#!/bin/sh
portvar="PORT=5000"
echo $portvar
grep -q $portvar /etc/environment && echo "EV already in" || echo $portvar >> /etc/environment
set -a; source /etc/environment; set +a;
When I run it, I get the error ./test.sh: 5: ./test.sh: source: not found. However, if I run set -a; source /etc/environment; set +a; directly in the terminal it updates the environmental variable just fine. I have no idea what the set command does, I just found it in another stack overflow question.
Any idea why it runs in the terminal directly but not in the .sh file?
Thanks
/bin/sh on your system is likely some shell that isn't bash and doesn't implement the source command. On my Ubuntu 20.04 system /bin/sh is actually dash.
The source command is not defined by POSIX as part of the shell command language nor is it one of the required special built-in utilities. It's a non-standard feature provided by bash. However, the . command, which does the same thing, is specified by POSIX.
So you can use . instead, e.g. . /etc/environment. Or if you want to keep using source, then you need to have your script run by bash or some other shell that supports it, by changing the shebang line to #!/bin/bash.
There is a tool called checkbashisms that can help you find unintentional uses of bash-specific features in your scripts. When run on your script, it flags this:
possible bashism in foo.sh line 5 (should be '.', not 'source'):
zsh doesn't recognize options set with -o, but only when its in a shebang, and on Linux.
The following script fails on zsh 5.0.2, zsh 5.6, and the latest git:
#!/bin/zsh -o pipefail
thiswillfail | echo 'hello, world'
echo $?
exit
Expected Output
hello, world
/home/prajjwal/script:2: command not found: thiswillfail
127
Actual Output
/bin/zsh: no such option: pipefail
What works
The script on zsh 5.3 on MacOS Mojave. This appears to be failing on every Linux version I've tried so far, though.
Manually invoking /bin/zsh -o pipefail on a terminal
Setting the option with set -o pipefail after the shebang in the script.
What I've tried
Emptying my .zshrc's to ensure one of my settings isn't causing this.
Aside
While I'm only trying to get pipefail to work, this refuses to work with any other options that I try to set, even though all of them are mentioned in zshoptions.
This is a pitfall of trying to set options on the #! line. The kernel only splits the shebang line at the first space.
When you say
#!/bin/zsh -o pipefail
the command that ends up being executed is "/bin/zsh" "-o pipefail" "/home/prajjwal/script".
The error message says that " pipefail" (note the leading space) is not a valid option, which is correct: Only "pipefail" is valid.
In this case a possible workaround is to cram everything into a single command line argument:
#!/bin/zsh -opipefail
But in general that's not possible and the #! interface doesn't let you pass more than one extra argument, so your choices are to find other workarounds (e.g. using set manually) or to write a wrapper script:
#!/bin/zsh
exec /bin/zsh -o pipefail /path/to/the/real/script
On some systems another alternative is available: env -S. This option is not specified by POSIX and is not available on all systems. It works on systems using the GNU tools (including all standard Linux distributions) and FreeBSD, but not OpenBSD or NetBSD. I couldn't find any information about MacOS.
(Note: GNU env also supports --split-string as an alternative (long) option name, but FreeBSD env does not.)
Usage:
#!/usr/bin/env -S /bin/zsh -o pipefail
This invokes env with a single long argument ('-S /bin/zsh -o pipefail'). Standard option processing treats it as the -S option followed by an argument (' /bin/zsh -o pipefail').
In a simple case like this, env -S splits the argument on spaces/tabs and treats the resulting list as if it had been part of the original command line in the first place:
env -S ' /bin/zsh -o pipefail'
# works the same as:
env /bin/zsh -o pipefail
In less simple cases you'll have to quote some characters (env -S treats spaces, ", ', \, $ specially, among others). In particular, it does not work like shell quoting. For details refer to the manual pages linked above.
I have no idea how tab completion works, but all of a sudden mine is broken. I don't even know what info to provide other than the use case.
there is a target clean in the makefile.
$ make c<tab> results in
$ make c23:set: command not found
lean
EDIT:
I believe somehow I ruined the set bash built-in since man set says No manual entry for set and which set doesn't report anything. Invoking set on the terminal, however, produces result.
I'm using: GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu) and GNU Make 3.81
thanks to Etan's comment and Aaron's indication of where makefiles are, I managed to debug this.
I ran set -x so I could track what was happening when doing the tab completion. The output of make c<tab> consists mostly of commands from the bash completion file for make, located at /usr/share/bash-completion/completions/make (1).
However, I noticed the an inconsistency between the output and the file. Towards the end, the output said:
+ local mode=--
+ (( COMP_TYPE != 9 ))
++ set +o
++ grep --colour=auto -n -F posix
+ local 'reset=23:set +o posix'
+ set +o posix
Which I identified as corresponding to these lines from the file:
if (( COMP_TYPE != 9 )); then
mode=-d # display-only mode
fi
local reset=$( set +o | grep -F posix ); set +o posix # for <(...)
So the output did a grep --colour=auto -n instead of just grep. Indeed, I had setup this alias for grep
Make worked as soon as I removed the alias.
I hope this helps others debug their problems.
EDIT: I have submitted a bug report here: https://alioth.debian.org/tracker/index.php?func=detail&aid=315108&group_id=100114&atid=413095
Look into /etc/bash_completion, /etc/bash_completion.d and/or /usr/share/bash-completion/completions. You should find a file make which contains the script that will be called when press Tab.
Use the packaging system of your Linux distro to validate the file (or maybe revert to an older version).
Another cause of this could be something in the Makefile which throws the parser in the BASH completion script off the track.
Not trying to get any credits here, but the best solution is actually a bit hidden in the comments...
Please vote this comment up instead of my answer!
easy steps to fix this:
sudo vi /usr/share/bash-completion/completions/make
find the line that has the grep instruction. It should look like this:
local reset=$( set +o | grep -F posix ); set +o posix # for <(...)
add a "\" before the "grep" instruction:
local reset=$( set +o | \grep -F posix ); set +o posix # for <(...)
Just updated cygwin to 1.7.28 on Windows 7.
Previously when starting X, the xterm would open with bash. For some reason it is now opening with sh?
What configuration changes do I need to make so that bash is the default shell again?
Not sure why this change happened.
The shortcut to open the xterm is the same as it was during my initial installation.
C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe
But it still starts with the default shell set to sh.
I don't understand what changed.
My passwd file is the same as it was before.
It appears that everything starts fine with the standard shortcuts, but the X and xterm startups are not sourcing /etc/profile
I had /etc/shells already (upgraded from ??? to 1.7.29), might have been new with upgrade, but still didn't work (xterm running sh instead of bash). Changed permissions on bash to fix.
It was 700 changed to 755
chmod 755 /bin/bash
xterm seems to need the /etc/shells file to be present to work. Add an /etc/shells file with the following contents:
# /etc/shells: valid login shells
/bin/csh
/bin/sh
/bin/bash
/bin/tcsh
/usr/bin/csh
/usr/bin/sh
/usr/bin/bash
/usr/bin/tcsh
Chris
Run following command to set bash as default shell.
set shell=C:/cygwin/bin/bash
Note path C:/cygwin/bin/bash may vary.
(Removed answer regarding /etc/passwd)
I tried your command on my cygwin and got the same behavior, i.e. xterm loaded with /bin/sh.
However, if I simply ran startxwin.exe directly, I get an xterm loaded with /bin/bash.
Dunno if this works for you, but, worth a try.
I had the same issue with sh launching, but managed a different workaround after having issues with /etc/shells
I also wanted to get rid of the default white /bin/sh xterm that startxwin.exe created.
It turns out there's a .startxwinrc that startxwin.exe sources, so I had it do this:
# Launch prettier xterms with bash
. ./.profile
# Exit the cruddy white xterm launched by startxwin
exit
The dot-space syntax above is equivalent to "source" in bash, but is more shell-independent.
Is it possible to check a bash script syntax without executing it?
Using Perl, I can run perl -c 'script name'. Is there any equivalent command for bash scripts?
bash -n scriptname
Perhaps an obvious caveat: this validates syntax but won't check if your bash script tries to execute a command that isn't in your path, like ech hello instead of echo hello.
Time changes everything. Here is a web site which provide online syntax checking for shell script.
I found it is very powerful detecting common errors.
About ShellCheck
ShellCheck is a static analysis and linting tool for sh/bash scripts. It's mainly focused on handling typical beginner and intermediate level syntax errors and pitfalls where the shell just gives a cryptic error message or strange behavior, but it also reports on a few more advanced issues where corner cases can cause delayed failures.
Haskell source code is available on GitHub!
I also enable the 'u' option on every bash script I write in order to do some extra checking:
set -u
This will report the usage of uninitialized variables, like in the following script 'check_init.sh'
#!/bin/sh
set -u
message=hello
echo $mesage
Running the script :
$ check_init.sh
Will report the following :
./check_init.sh[4]: mesage: Parameter not set.
Very useful to catch typos
sh -n script-name
Run this. If there are any syntax errors in the script, then it returns the same error message.
If there are no errors, then it comes out without giving any message. You can check immediately by using echo $?, which will return 0 confirming successful without any mistake.
It worked for me well. I ran on Linux OS, Bash Shell.
I actually check all bash scripts in current dir for syntax errors WITHOUT running them using find tool:
Example:
find . -name '*.sh' -print0 | xargs -0 -P"$(nproc)" -I{} bash -n "{}"
If you want to use it for a single file, just edit the wildcard with the name of the file.
null command [colon] also useful when debugging to see variable's value
set -x
for i in {1..10}; do
let i=i+1
: i=$i
done
set -
For only validating syntax:
shellcheck [programPath]
For running the program only if syntax passes, so debugging both syntax and execution:
shellproof [programPath]
Bash shell scripts will run a syntax check if you enable syntax checking with
set -o noexec
if you want to turn off syntax checking
set +o noexec
There is BashSupport plugin for IntelliJ IDEA which checks the syntax.
If you need in a variable the validity of all the files in a directory (git pre-commit hook, build lint script), you can catch the stderr output of the "sh -n" or "bash -n" commands (see other answers) in a variable, and have a "if/else" based on that
bashErrLines=$(find bin/ -type f -name '*.sh' -exec sh -n {} \; 2>&1 > /dev/null)
if [ "$bashErrLines" != "" ]; then
# at least one sh file in the bin dir has a syntax error
echo $bashErrLines;
exit;
fi
Change "sh" with "bash" depending on your needs