So I was trying to create little .sh script for my work and run into one little problem.
My cygwin terminal (x64) runs just fine and I'm using it often enough to do manual greps.
In the begging I had some issues with this command but now it works fine in cygwin terminal.
Once I wrote my little script and tried to run it only output I'm getting is "line 6: grep: command not found"
My execution method is:
Open cygwin terminal
cd to script location
type in ./script.sh
enter :)
Anyone knows how to fix that? I already added cygwin bin folder to my system path (Win 10 btw) but that didn't helped. Looked around for a while but haven't found anything useful, mostly issues with grep itself.
my script for reference:
mkdir -p output
PATH=$PWD"/output"
while IFS=";" read -r component location global
do
cd $location
grep -iRl $global --exclude-dir={wrongdir1,wrongdir2} > $PATH"/"$component".txt"
done < input.csv
you're overwriting you Cygwin system path: PATH=$PWD"/output" - instead of PATH use a diff var name.
Related
I have installed Atom editor natively on Windows 10 by downloading an running the installer. Now I start WSL Ubuntu distro and want to start Atom (atom-editor) from there with the command atom . or VSCode (visual-studio-code) with the command code .
Atom starts, but not in the directory where the command was executed, instead it shows files from C:\\Windows. Moreover Ubuntu WSL terminal shows following error message:
atom .
grep: /etc/wsl.conf: No such file or directory
"\\wsl$\Ubuntu-18.04\home\wlad\projects\udemy\flask-bootcamp\Flask-Bootcamp-master"
CMD.EXE wurde mit dem oben angegebenen Pfad als aktuellem Verzeichnis gestartet.
UNC-Pfade werden nicht unterstützt.
Stattdessen wird das Windows-Verzeichnis als aktuelles Verzeichnis gesetzt.
Sorry it's German localized but it says something like UNC-paths are not supported
(haven't tested VSCode yet)
So how can I use Atom or VSCode editor installed on Windows 10 from within WSL?
** UPDATE **
As of today (April 2020) there is a much better way to use VSCode on Windows w/ WSL, VirtualMachines (VM) and even Containers. Check out remote-development plugin for VSCode.
I created a short script to handle the three atom commands I use most (I use Ubuntu with WSL):
atom
atom .
atom RELATIVE_PATH_FILE
This script is not optimized, and I'm sure many people will find edge cases, but it gets the job done for me. To use it, simply placed it in ~/.local/bin/atom and make it executable by running chmod +x ~/.local/bin/atom. You may need to restart your shell for ~/.local/bin to be added to your path. In order to simplify things a bit, I mapped the WSL network drive for my ubuntu installation to U:, so you'll either want to do the same or modify the script accordingly on line 9.
#!/bin/bash
if [ -z $1 ]; then
pushd /mnt/c > /dev/null
/mnt/c/Windows/System32/cmd.exe /c "atom"
else
[[ $1 = "." ]] && path=$(pwd) || path=$(realpath $1)
winPath=$(echo "U:$path" | sed -e 's/\//\\/g')
pushd /mnt/c > /dev/null
/mnt/c/Windows/System32/cmd.exe /c "atom $winPath"
fi
popd > /dev/null
The script performs a few simple steps. First, if there is no command line argument, it simply calls atom using cmd.exe without arguments. If the command line argument is ., it gets the path to the current directory, otherwise, it gets the absolute path to the given file using realpath. The path is converted from POSIX to Windows format using sed before calling atom using cmd.exe as before, but with the path argument.
The pushd and popd commands are just there to get rid of the annoying warning message about UNC paths not being supported:
...
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory
In the "Known issues" section of the blog post #Wlad mentioned, there states
Accessing Linux files is treated the same as accessing a network resource, and any rules for accessing network resources will still apply e.g: When using CMD, cd \\wsl$\Ubuntu\home will not work (as CMD does not support UNC paths as current directories), however copy \\wsl$\Ubuntu\home\somefile.txt C:\dev\ will work
So as Atom may use cmd.exe to launch itself from the command line (maybe some batch file), and given the fact that cmd.exe cannot open network resources as current directory (which WSL directory is treated as), there came the failure as you attempted to launch Atom from WSL shell.
Actually, in VS Code there is a better solution to launch VS Code directly from the WSL shell: VS Code Remote.
You can take the following steps to enable VS Code to be directly launched from WSL shell：
Install the extension Remote - WSL to VS Code on the Windows side;
Then when you type code . in your WSL shell, VS Code Remote Server will be automatically installed, and VS Code will soon launch.
By using VS Code Remote, you can not only open the directory in VS Code, but can also be benefited in many other aspects: for example, you can use the WSL shell as the integrated shell in VS Code and run programs in WSL directly from VS Code.
Here is the official doc for VS Code Remote - WSL.
The script in Eduardo's answer is a great approach, but didn't allow to open multiple directories/repos at once (e.g. atom terraform-modules terraform-repo), which I do often.
The following is my twist on it:
#!/bin/bash
winPathPrefix="U:"
function convertToWinPath() {
echo "${winPathPrefix}$(realpath ${1})" | sed -e 's/\//\\/g'
}
declare -a atomCmd=(/mnt/c/Windows/System32/cmd.exe /c "atom")
for path in "$#"; do
atomCmd+=($(convertToWinPath ${path}))
done
${atomCmd[#]} 2>/dev/null
That is entirely based on Eduardo's script and should allow a more general use case
Wanting to run Atom from WSL got me here but unfortunately the accepted answer does not mention atom and the other atom related workarounds don't work anymore.
In case someone googles the question and ends up here. Here's an actual workaround (It will break in new Atom updates).
Add the following path path in the windows enviroments: C:\Users\{username}\AppData\Local\atom\app-{version}\ (at the time of this post the version is 1.60.0 so app-1.60.0.
Use the path mentioned above as the default path contains a bash executable that will be run fail to run in wsl.
Here's where it will break in future updates. The fix is to update the env in windows to the new path since the folder where the exe is located will change to match atom's version.
Add the following in your .bashrc or .zshrc:
Important to be added in .bashrc or .zshrc as making a separate script in /usr/bin will always make atom to open in the C:/Windows folder.
function _atom () { exec nohup atom.exe "$#" &> /dev/null & } # Do not output in terminal and do not block the terminal. Also send the command arguments to atom.
alias atom="_atom"
Open a new wsl terminal.
I wrote a bash script to open atom with and without files from WSL2. It can handle any number (including 0) of file arguments, on any drive. Both relative and absolute paths are supported, but it can't handle path name containing .. or ~. Pointing atom to a director also works as expected. Here's my script:
#!/bin/bash
atom_cmd="/mnt/c/Users/`whoami`/AppData/Local/atom/atom.exe"
for i in "$#"; do
if [[ $i == /mnt* ]]; then
linPath="$i" #for absolute file paths
else
linPath="`pwd`/$i" #for relative file paths
fi
if [[ $linPath == *".."* || $linPath != "/mnt"* || $i == "/home"* ]] ; then
echo "atom script is unacceptable file path $linPath"
continue 1
fi
winPath="\""`echo $linPath | sed -e 's|\/mnt\/\([a-z]\)|\u\1:|' -e 's:\/:\\\\:g'`""
atom_cmd="$atom_cmd $winPath\""
done
unset linPath
unset winPath
echo "command:" "$atom_cmd"
eval "$atom_cmd"
unset atom_cmd
(I'm sure there are things to improve about this, like edge cases and better use of language features. I'd welcome suggestions.)
this can be a little bit outdated but you can simply run a powershell and use:
wsl.exe -d Ubuntu-20.04 //In my case ubuntu
This should open a ubuntu session or whatever wsl you have set on your own.
A little bit nooby on this but trying to help. =)
I have had a hard time in executing my shell scripts on bash on Ubuntu on windows 10. The script is very simple:
# file name: submission.sh
echo "Hello world" > output.txt
When I executed it with a command sh submission.sh, it gave me an error:
$ sh submission.sh
: Directory nonexistentssion.sh: cannot create output.txt
However, when I changed the script into
# file name: submission.sh
echo "Hello world"
and executed it with the same command sh submission.sh, it gave me the right output
$ sh submission.sh
Hello world
It seems like bash on Ubuntu on Windows cannot get it right when the script involves directing the output to a file. Is there any solution or workaround to this?
EDIT:
Details on my system:
Program: "Bash on Ubuntu on Windows"
OS: Windows 10 Version 1709
EDIT:
Typing the command directly on the terminal works, i.e.
$ echo "Hello world" > output.txt
$ cat output.txt
Hello world
I still wants to put the commands on a file and execute the file instead of writing the command directly to the terminal, and this is still unsolved.
You appear to have mangled text in nonexistentssion.sh: and No such file or directorytput.txt which suggests you might have Windows line-endings in the file \r. If you created the script using a Windows program (like Notepad) then that could be the case.
If you have dos2unix then run it on your script and try again.
By the way for future reference, running sh is not the same as running bash. In this case it would have made no difference, but sh is a POSIX shell, full bash has many extensions which will not work under sh.
Some platforms run sh as a symbolic link to bash which fools people into thinking they are the same, but bash detects this and switches to POSIX mode when running as sh. It is a common issue here.
In your submission.sh file, is better to add a shebang as first line.
Another thing you want to consider if you want to use sh instead of bash is to replace echo with printf, for portability
Your code should look something like:
#!/bin/bash
printf "Hello world!\n" > output.txt
You can call it simply by ./submission.sh and because of the shebang, your terminal will know how to open it [:
P.S. Keep in mind that because of the standard umask in Ubuntu, you might want to execute chmod u+x submission.sh before running it.
Also, notice that your error is probably caused by a permissions issue.
Try adding write permissions in the folder you are launching the script.
I am unfortunately having to use windows in work, and so I have installed win-bash to have a unix shell running. all going well but I am having an issue running the following .sh file:
bash $ ./qf.sh
.\qf.sh: option not available on this NT BASH release
.\qf.sh: fork: Bad file descriptor
qf.sh is:
#!/bin/bash
cat test.csv | while read line
do
echo "${line//,/ }" | xargs ./adder
done
I find it hard to believe someone would create a bash emulator incapable of running a bash file. curious that the error message writes .\qf as opposed to ./qf
Can anyone shed some light on this?
use MinGW or Cygwin
MinGW: http://sourceforge.net/projects/mingw/files/?source=navbar
Cygwin: http://www.cygwin.com/
Using Cygwin absolutely killed this error for me. I do wonder however, how this should work with MinGW. I don't see any unix command executable directory to include in the path (like cygwin64\bin with Cygwin)
How to create a bash file?
I found following bash script.
#!/bin/bash
for f in *.wav; do
echo "Processing $f file..."
afconvert -f caff -d LEI16#44100 -c 1 "$f" "${f/wav/caf}"
done
I have Mac and Windows.
But I don't know where I have to put this and how I can run this script?
Just save the text into a file called my_bash_script a file, make it executable and run it from the command line like this:
chmod u+x my_bash_script
./my_bash_script
Judging by the file it will need to be in a directory containing *.wav files.
As you have two different OS setup, I will split my answer in two parts.
First: Windows
Windows does not have a Bash interpreter, nor the afconvert program the code above is trying tu run. Your best bet will be to use Cygwin to install a Unix console on your Windows. Also I don't know, where you could get afconvert from.
OSX
OSX does have a console and the afconvert software (at least my OSX does). You can simply drop the file in a folder and give it a name ending in .sh. Then you should be able to run it.
Just paste the text into a plaint text file and then mark it as executable:
chmod +x yourScript
To run it:
./yourScript
Place the script anywhere you have your .wav files. When fallow instructions given here:
http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_01.html#sect_02_01_03
mvim is installed in /usr/local/bin/ but can not be used as either EDITOR or VISUAL:
$ mvim -f # works as expected
$ EDITOR="/usr/local/bin/mvim -f" crontab -e
crontab: /usr/local/bin/mvim -f: No such file or directory
crontab: "/usr/local/bin/mvim -f" exited with status 1
I tried single quotes and using VISUAL instead of EDITOR. Same result. I also tried googling, but apparently the -f flag works just fine for everybody else.
I use Mac OS 10.6.6 and zsh, but the problem is the same in bash.
The problem is crontab expects to be able to run a program called "/usr/local/bin/mvim -f" if you supply that in the EDITOR environment variable.
To get around that, you could write a short shell script. For example, call this one mvimf:
#!/bin/bash
/usr/local/bin/mvim -f "$#"
Then you can run: EDITOR=/usr/local/bin/mvimf crontab -e
I am not sure if this is directly related to the problem you are having but I was seeing a similar error code when trying to edit my crontab. I realized I had a little conflict in my vimrc file related to the pathogen plugin. If you call:
filetype off
when it's already off you can cause problems that will make your Vim exit with errors. Sounds like your issue is fixed already, but since this shows up in searches related to this error code, I thought I would post it here.
Credit goes to commenters on this post - http://tooky.github.com/2010/04/08/there-was-a-problem-with-the-editor-vi-git-on-mac-os-x.html
For those seeing this without mvim, you can use morton-fox's answer for any editor:
EDITOR=/usr/bin/vim crontab -e
Will use vim to open the crontab file