I am making an NW.js app on macOS, and want to run the app in dev mode
by double-clicking on an icon.
In the first step, I'm trying to make my shell script work.
Using VS Code on Windows (I wanted to gain time), I have created a run-nw file at the root of my project, containing this:
#!/bin/bash
cd "src"
npm install
cd ..
./tools/nwjs-sdk-v0.17.3-osx-x64/nwjs.app/Contents/MacOS/nwjs "src" &
but I get this output:
$ sh ./run-nw
: command not found
: No such file or directory
: command not found
: No such file or directory
Usage: npm <command>
where <command> is one of: (snip commands list)
(snip npm help)
npm#3.10.3 /usr/local/lib/node_modules/npm
: command not found
: No such file or directory
: command not found
Some things I don't understand.
It seems that it takes empty lines as commands.
In my editor (VS Code) I have tried to replace \r\n with \n
(in case the \r creates problems) but it changes nothing.
It seems that it doesn't find the folders
(with or without the dirname instruction),
or maybe it doesn't know about the cd command ?
It seems that it doesn't understand the install argument to npm.
The part that really weirds me out, is that it still runs the app
(if I did an npm install manually)...
Not able to make it work properly, and suspecting something weird with
the file itself, I created a new one directly on the Mac, using vim this time.
I entered the exact same instructions, and... now it works without any
issues.
A diff on the two files reveals exactly zero difference.
What can be the difference? What can make the first script not work? How can I find out?
Update
Following the accepted answer's recommendations, after the wrong line
endings came back, I checked multiple things.
It turns out that since I copied my ~/.gitconfig from my Windows
machine, I had autocrlf=true, so every time I modified the bash
file under Windows, it re-set the line endings to \r\n.
So, in addition to running dos2unix (which you will have to
install using Homebrew on a Mac), if you're using Git, check your
.gitconfig file.
Yes. Bash scripts are sensitive to line-endings, both in the script itself and in data it processes. They should have Unix-style line-endings, i.e., each line is terminated with a Line Feed character (decimal 10, hex 0A in ASCII).
DOS/Windows line endings in the script
With Windows or DOS-style line endings , each line is terminated with a Carriage Return followed by a Line Feed character. You can see this otherwise invisible character in the output of cat -v yourfile:
$ cat -v yourfile
#!/bin/bash^M
^M
cd "src"^M
npm install^M
^M
cd ..^M
./tools/nwjs-sdk-v0.17.3-osx-x64/nwjs.app/Contents/MacOS/nwjs "src" &^M
In this case, the carriage return (^M in caret notation or \r in C escape notation) is not treated as whitespace. Bash interprets the first line after the shebang (consisting of a single carriage return character) as the name of a command/program to run.
Since there is no command named ^M, it prints : command not found
Since there is no directory named "src"^M (or src^M), it prints : No such file or directory
It passes install^M instead of install as an argument to npm which causes npm to complain.
DOS/Windows line endings in input data
Like above, if you have an input file with carriage returns:
hello^M
world^M
then it will look completely normal in editors and when writing it to screen, but tools may produce strange results. For example, grep will fail to find lines that are obviously there:
$ grep 'hello$' file.txt || grep -x "hello" file.txt
(no match because the line actually ends in ^M)
Appended text will instead overwrite the line because the carriage returns moves the cursor to the start of the line:
$ sed -e 's/$/!/' file.txt
!ello
!orld
String comparison will seem to fail, even though strings appear to be the same when writing to screen:
$ a="hello"; read b < file.txt
$ if [[ "$a" = "$b" ]]
then echo "Variables are equal."
else echo "Sorry, $a is not equal to $b"
fi
Sorry, hello is not equal to hello
Solutions
The solution is to convert the file to use Unix-style line endings. There are a number of ways this can be accomplished:
This can be done using the dos2unix program:
dos2unix filename
Open the file in a capable text editor (Sublime, Notepad++, not Notepad) and configure it to save files with Unix line endings, e.g., with Vim, run the following command before (re)saving:
:set fileformat=unix
If you have a version of the sed utility that supports the -i or --in-place option, e.g., GNU sed, you could run the following command to strip trailing carriage returns:
sed -i 's/\r$//' filename
With other versions of sed, you could use output redirection to write to a new file. Be sure to use a different filename for the redirection target (it can be renamed later).
sed 's/\r$//' filename > filename.unix
Similarly, the tr translation filter can be used to delete unwanted characters from its input:
tr -d '\r' <filename >filename.unix
Cygwin Bash
With the Bash port for Cygwin, there’s a custom igncr option that can be set to ignore the Carriage Return in line endings (presumably because many of its users use native Windows programs to edit their text files).
This can be enabled for the current shell by running set -o igncr.
Setting this option applies only to the current shell process so it can be useful when sourcing files with extraneous carriage returns. If you regularly encounter shell scripts with DOS line endings and want this option to be set permanently, you could set an environment variable called SHELLOPTS (all capital letters) to include igncr. This environment variable is used by Bash to set shell options when it starts (before reading any startup files).
Useful utilities
The file utility is useful for quickly seeing which line endings are used in a text file. Here’s what it prints for for each file type:
Unix line endings: Bourne-Again shell script, ASCII text executable
Mac line endings: Bourne-Again shell script, ASCII text executable, with CR line terminators
DOS line endings: Bourne-Again shell script, ASCII text executable, with CRLF line terminators
The GNU version of the cat utility has a -v, --show-nonprinting option that displays non-printing characters.
The dos2unix utility is specifically written for converting text files between Unix, Mac and DOS line endings.
Useful links
Wikipedia has an excellent article covering the many different ways of marking the end of a line of text, the history of such encodings and how newlines are treated in different operating systems, programming languages and Internet protocols (e.g., FTP).
Files with classic Mac OS line endings
With Classic Mac OS (pre-OS X), each line was terminated with a Carriage Return (decimal 13, hex 0D in ASCII). If a script file was saved with such line endings, Bash would only see one long line like so:
#!/bin/bash^M^Mcd "src"^Mnpm install^M^Mcd ..^M./tools/nwjs-sdk-v0.17.3-osx-x64/nwjs.app/Contents/MacOS/nwjs "src" &^M
Since this single long line begins with an octothorpe (#), Bash treats the line (and the whole file) as a single comment.
Note: In 2001, Apple launched Mac OS X which was based on the BSD-derived NeXTSTEP operating system. As a result, OS X also uses Unix-style LF-only line endings and since then, text files terminated with a CR have become extremely rare. Nevertheless, I think it’s worthwhile to show how Bash would attempt to interpret such files.
On JetBrains products (PyCharm, PHPStorm, IDEA, etc.), you'll need to click on CRLF/LF to toggle between the two types of line separators (\r\n and \n).
I was trying to startup my docker container from Windows and got this:
Bash script and /bin/bash^M: bad interpreter: No such file or directory
I was using git bash and the problem was about the git config, then I just did the steps below and it worked. It will configure Git to not convert line endings on checkout:
git config --global core.autocrlf input
delete your local repository
clone it again.
Many thanks to Jason Harmon in this link:
https://forums.docker.com/t/error-while-running-docker-code-in-powershell/34059/6
Before that, I tried this, that didn't works:
dos2unix scriptname.sh
sed -i -e 's/\r$//' scriptname.sh
sed -i -e 's/^M$//' scriptname.sh
If you're using the read command to read from a file (or pipe) that is (or might be) in DOS/Windows format, you can take advantage of the fact that read will trim whitespace from the beginning and ends of lines. If you tell it that carriage returns are whitespace (by adding them to the IFS variable), it'll trim them from the ends of lines.
In bash (or zsh or ksh), that means you'd replace this standard idiom:
IFS= read -r somevar # This will not trim CR
with this:
IFS=$'\r' read -r somevar # This *will* trim CR
(Note: the -r option isn't related to this, it's just usually a good idea to avoid mangling backslashes.)
If you're not using the IFS= prefix (e.g. because you want to split the data into fields), then you'd replace this:
read -r field1 field2 ... # This will not trim CR
with this:
IFS=$' \t\n\r' read -r field1 field2 ... # This *will* trim CR
If you're using a shell that doesn't support the $'...' quoting mode (e.g. dash, the default /bin/sh on some Linux distros), or your script even might be run with such a shell, then you need to get a little more complex:
cr="$(printf '\r')"
IFS="$cr" read -r somevar # Read trimming *only* CR
IFS="$IFS$cr" read -r field1 field2 ... # Read trimming CR and whitespace, and splitting fields
Note that normally, when you change IFS, you should put it back to normal as soon as possible to avoid weird side effects; but in all these cases, it's a prefix to the read command, so it only affects that one command and doesn't have to be reset afterward.
Coming from a duplicate, if the problem is that you have files whose names contain ^M at the end, you can rename them with
for f in *$'\r'; do
mv "$f" "${f%$'\r'}"
done
You properly want to fix whatever caused these files to have broken names in the first place (probably a script which created them should be dos2unixed and then rerun?) but sometimes this is not feasible.
The $'\r' syntax is Bash-specific; if you have a different shell, maybe you need to use some other notation. Perhaps see also Difference between sh and bash
Since VS Code is being used, we can see CRLF or LF in the bottom right depending on what's being used and if we click on it we can change between them (LF is being used in below example):
We can also use the "Change End of Line Sequence" command from the command pallet. Whatever's easier to remember since they're functionally the same.
For Notepad++ users, this can be solved by:
One more way to get rid of the unwanted CR ('\r') character is to run the tr command, for example:
$ tr -d '\r' < dosScript.py > nixScript.py
I ran into this issue when I use git with WSL.
git has a feature where it changes the line-ending of files according to the OS you are using, on Windows it make sure the line endings are \r\n which is not compatible with Linux which uses only \n.
You can resolve this problem by adding a file name .gitattributes to your git root directory and add lines as following:
config/* text eol=lf
run.sh text eol=lf
In this example all files inside config directory will have only line-feed line ending and run.sh file as well.
The simplest way on MAC / Linux - create a file using 'touch' command, open this file with VI or VIM editor, paste your code and save. This would automatically remove the windows characters.
If you are using a text editor like BBEdit you can do it at the status bar. There is a selection where you can switch.
For IntelliJ users, here is the solution for writing Linux script.
Use LF - Unix and masOS (\n)
Scripts may call each other.
An even better magic solution is to convert all scripts in the folder/subfolders:
find . -name "*.sh" -exec sed -i -e 's/\r$//' {} +
You can use dos2unix too but many servers do not have it installed by default.
For the sake of completeness, I'll point out another solution which can solve this problem permanently without the need to run dos2unix all the time:
sudo ln -s /bin/bash `printf 'bash\r'`
Is there a way to tail a file by name on Solaris 10?
Equivalent to:
tail --follow=name
Manual for tail on solaris shows no such option. Only -f is included and it looks like it follows a file by descriptor.
According to the GNU tail manual, --follows is the same as -f:
-f, --follow[={name|descriptor}]
output appended data as the file grows;
an absent option argument means 'descriptor'
A -f option is found in the POSIX description of tail. However, the --follows option (which accepts an option value) is not in POSIX. The GNU manual goes on to describe the --follow option where it differs from -f:
With --follow (-f), tail defaults to following the file descriptor,
which means that even if a tail'ed file is renamed, tail will
continue to track its end. This default behavior is not desirable
when you really want to track the actual name of the file, not the
file descriptor (e.g., log rotation). Use --follow=name in that
case. That causes tail to track the named file in a way that
accommodates renaming, removal and creation.
That is, --follow provides for reopening the file if the actual file was renamed. POSIX does not appear to address this use case.
There is no direct equivalent in Solaris's differences from POSIX (compare /usr/bin/tail and /usr/xpg4/bin/tail in manual).
GNU tail is part of the coreutils package. You may already have it installed on Solaris 10, in /opt/sfw/bin/tail. For instance, pkginfo shows it on my Solaris 10 machine as SFWcoreu.
Solaris does not have --follow as you see.
The workaround is redirection:
tail -f inputfile > filewritten_by_tail
Your best bet is to install GNU find either from source or some freeware repository.
If you really want to stick with Solaris 10 bundled find, you'll need to wrap it with a custom monitoring program that will restart it should the target file is renewed.
Works like a charm on solaris 11!
/usr/bin/gtail -F
I am trying to figure out a way to make the weblogic WLST terminal run in silent mode.
When i start the terminal with the java weblogic.WLST command, it prints the lines:
Initializing WebLogic Scripting Tool (WLST) ...
Welcome to WebLogic Server Administration Scripting Shell
Type help() for help on available commands
Is there a command line flag or some unknown witchcraft to make the interpreter not write these lines?
I wishfully tried -s for silent, to no avail.
And all my googling lead me to an -i flag that does something completely different.
EDIT:
To clarify my purpose:
I need the interpreter to run a python script, and i do need the output from that. The welcome message is useless clutter however, that i would like to be rid of.
Limited to:
The only problem i have is the first lines written by the interpreter itself. Once inside the python script i have no problem handling what send to the output. My only problem is the welcome lines written above. These are written by the interpreter itself, and not the python code.
To solve the problem, I did something little differente..
I put a grep -v in the output .. like this:
java weblogic.WLST script.py $ARGS | grep -v "Initializing WebLogic
Scripting Tool (WLST) ..." | grep -v "Welcome to WebLogic Server
Administration Scripting Shell" | grep -v "Type help() for help on
available commands" | grep -v "Successfully connected to Admin Server
\"AdminServer\" that belongs to domain \"domain\"." | grep -v
"Warning: An insecure protocol was used to connect to the server." |
grep -v "To ensure on-the-wire security, the SSL port or Admin port
should be used instead." | grep -v "Location changed to domainRuntime
tree. This is a read-only tree" | grep -v "with DomainMBean as the
root MBean." | grep -v "For more help, use help('domainRuntime')" |
grep -v "Successfully connected to Admin Server" | grep -v "Connecting
to t3://"
Try this:
Like you said "it's a hack", but it's a fairly elegant hack.
Create the file runwlst.sh:
#!/bin/bash
. ${WLS_HOME}/server/bin/setWLSEnv.sh >/dev/null 2>&1
FILENAME=$1
shift
java weblogic.WLST ${FILENAME} "$#" | sed -e "1,7 d"
WLS_HOME needs to be set, or use the absolute path to setWLSEnv.sh.
Then create your WLST scripts as "shell" scripts like so (I like to use the ".wlsh" extension for my scripts):
#!/bin/bash /absolute_path_to_runwlst.sh/runwlst.sh
# your WLST Python code starts here
import ...
This obviously the sed script used in runwlst.sh only works if the "Initializing" banner is 7 lines long, which could change with new releases or patches of WLS.
The benefit of this solution is that now you can just run your WLST scripts from the command line like so:
$ createManagedServer.wlsh domain servername
Or use WLST scripts is other shell scipts like so:
#!/bin/bash
PORT=`./getPortForManagedServer.wlsh domain server`
echo ${PORT}
you get the picture
I wanted for it to only show me lines that I print inside the script, so I did it simple - prepended special char sequence to all lines I wanted to see in logs (it was print('--> ...') in my case) and launched it like that:
wlst.sh changePassword.wlst.py "$#" | grep -- "-->"
Sample output:
Executing WLST script for domain SampleDomain
--> Executing credential change for SampleDomain
--> Changing DB password for DSTYPE1
--> Changing password for DataSource SampleDS1
--> Successfully changed DB credentials!
--> Changing password for DataSource SampleDS2
--> No JDBC resource with name SampleDS2 found, skipping...
--> Changing password for DataSource SampleDS3
--> No JDBC resource with name SampleDS3 found, skipping...
--> Changing password for DataSource SampleDS4
--> Successfully changed DB credentials!
Completed execution for domain SampleDomain
Bit of a long shot but you could also silence the entire JVM output by capturing stdout and stderr into a different stream and then print values captured from the weblogic mbeans to the console streams. I had to do something similar a while back after writing an ansible module which required me to return pure JSON to stdout without any message banners or other stuff printed to the terminal.
A possible solution for your needs would involve writing a python script that first changes the OutputStreams as in this example and then starts a WSLT session. Just remember to keep a "copy" of the console out streams and use these to write your results to.
At the office, we have a shared user we use half the time. I'm trying to get screen to automatically load a custom bashrc file that I created for myself when using the shared user. So far I have this which works well:
alias screen='screen -d -R -S redhar -c /home/redhar/.screenrc bash -rcfile '\''/home/goldenuser/.bashrc_redhar'\'''
This works well for the very first window it creates. The problem comes when I create a new window. Is there anyway to get a newly created window to automatically use the same rcfile?
So far I have considered the following option, but I'm looking for a more streamlined solution along the lines of a missing GNU screen config option I overlooked or something. My proposed solution:
In regular .bashrc which gets loaded automatically:
if [[ $SCREENFLAG == "REDHAR" ]]
then
. /home/goldenuser/.bashrc_redhar
exit
fi
Set alias to:
alias screen='SCREENFLAG=REDHAR screen -d -R -S redhar -c /home/redhar/.screenrc bash -rcfile '\''/home/goldenuser/.bashrc_redhar'\'''
Discovered the solution is to create a file with
bash -rcfile /home/goldenuser/.bashrc_redhar
then set your shell command in .screenrc to it
shell='<path to file created above>'
Is there anyone that can explain to someone that doesn't know how to use Terminal what are the commands to use Transporter for iTunes Connect?
I tryed to follow the guide but with no results....
These are my steps till now:
I put this command in terminal:
export TRANSPORTER_HOME=`xcode-select --print-path`/../
Applications/Application\ Loader.app/Contents/MacOS/itms/bin
and my terminal change like this:
~ myname$ Applications/Application\ Loader.app/Contents/MacOS/itms/bin
so I guess with this now I am in the transporter folder...
Now I want to etrieve my app’s current metadata Using Lookup Mode, and I tryed with this command:
$ iTMSTransporter -m lookupMetadata -u [myname#gmail.com] -p [mypassword] -vendor_id [id999999999] -
destination [Applications/Application\ Loader.app/Contents/MacOS/itms/bin]
but I get this:
$ iTMSTransporter -m lookupMetadata -u [myname#gmail.com] -p [mypassword] -vendor_id [id999999999] -
-bash: Applications/Application Loader.app/Contents/MacOS/itms/bin$: No such file or directory
I assume I'm writing the destination in a wrong way....
So how should I write that command?
And also... when I will have to upload my edited file... what shoud I put?
Thanks a lot for any help with this issue
Start by putting the export command into a single line.
export TRANSPORTER_HOME=`xcode-select --print-path`/../Applications/Application\ Loader.app/Contents/MacOS/itms/bin
Then you have to use the full path to the iTMSTransporter Binary. You can use the variable you just defined for this.
"$TRANSPORTER_HOME/iTMSTransporter" -m lookupMetadata -u ... -vendor_id ... -destination ~/myapp
The destination is the directory where the app data will be put. ~ means your user directory. So if your username is blue ~/myapp means /Users/blue/myapp.
Don't use Xcodes directory for this.
I would recommend to NOT specify your password with the -p parameter. You don't want your password to appear in bash_history. If you don't specify the passwort you will be asked for it.
Again. Make sure that this is in one line. You must not spread the command over more than one line. Unfortunately if you copy and paste from the pdf document you get a multi line command that won't work.
I suggest to open a text editor, paste the command from the pdf into the text editor and format the command so it is on a single line.
Then go to https://bugreport.apple.com and file a bug about the crappy documentation of iTMSTransporter