I'm using the Windows Subsystem on Linux (Ubuntu) and would like to be able to run multiple processes in parallel from my bash script by creating multiple cmd-window instances of the Ubuntu shell. Is this possible?
I tried using gnome-terminal to run multiple commands via:
gnome-terminal -e "command"
But it returned the error:
Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error spawning command line 'dbus-launch --autolaunch= --binary-syntax --close-stderr': Child process exited with code 1
And it seemed like people were having trouble using gnome-terminal.
Any ideas for accomplishing this? Thanks.
For Windows 14393 and above:
cmd.exe /c start bash.exe -c ls
Related
I'm running Windows 10 x64 with WSL2 (Ubuntu 20.04 on WSL2).
In WSL2, I have cron running the following task:
* * * * * /mnt/c/Users/Colin/Desktop/test.sh
The contents of test.sh (currently executing every minute for test purposes) are as follows:
#!/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Windows/system32:/mnt/c/Windows:/mnt/c/Windows/System32
taskkill.exe /im calibre.exe
sleep 5
<rsync command here>
echo "Done with rsync, launching calibre..."
screen -dm bash -c \"/mnt/c/Users/Colin/Desktop/startcalibre.sh\"
This script works perfectly when executed from the WSL2 prompt.
However, cron will not run either the taskkill.exe command nor the screen command (which launches calibre) in the script. I do see that cron executes the script because I see that rsync runs since I can see that in Wireshark. It seems that cron on WSL2 has problems with running Windows executables (taskkill.exe, etc) in particular (I can't even seem to get notepad.exe to launch via a cron-executed script).
What should I add to the script to get cron to execute Windows executables?
Not necessarily an answer, but I'm hoping this will lead us to one ...
First, let's try a script that pretty much anyone with WSL can run to see if we can reproduce the problem in more of an MRE:
#!/usr/bin/env bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Windows/system32:/mnt/c/Windows:/mnt/c/Windows/System32
echo $PATH > ~/cronlogger
notepad.exe &
sleep 2
which taskkill.exe >> ~/cronlogger
taskkill.exe /im notepad.exe >> ~/cronlogger 2>&1
I placed this script in my %userprofile%/Desktop/test.sh as well and set it to run with the same crontab line (via sudo crontab -u ntd -e):
* * * * * /mnt/c/Users/ntd/Desktop/test.sh
It works for me as expected -- Every minute, Notepad pops up and then after 2 seconds is killed. The contents of ~/cronlogger are:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Windows/system32:/mnt/c/Windows:/mnt/c/Windows/System32
/mnt/c/Windows/system32/taskkill.exe
SUCCESS: Sent termination signal to the process "Notepad.exe" with PID 4268.
Of course, wait until a few seconds after the top of the minute to make sure you capture the whole thing.
I notice that you have the ..\System32 path twice, but that shouldn't matter. Also, case-sensitivity isn't an issue unless you have specifically turned it on for Windows drives via /etc/wsl.conf.
I tested this:
On Windows 10 21H2
On Windows 11 using the latest Preview version of WSL
As my normal user sudo crontab -u ntd -e
As the root user sudo crontab -e
All worked okay for me.
At this point, the only thing I can think that might throw it off is if you were using a Systemd script of some sort. I've seen Systemd throw off the WSL binfmt_misc registration so that WSL can no longer run Windows executables. I could imagine this could happen inside the Cron daemon (but still be working via the default shell).
I need to start a couple of processes locally in multiple command-prompt windows, to make it simple, I have written a shell script say abc.sh to run in git-bash which has below commands:
cd "<target_dir1>"
<my_command1> &>> output.log &
cd "<target_dir2>"
<my_command2> &>> output.log &
when I run these commands in git bash I get jobs running in the background, which can be seen using jobs and kill command, however when I run them through abc.sh, I get my processes running in the background, but the git-bash instance disowns them, now I can no longer see them using jobs.
how can I get them run through the abc.sh file and also able to see them in jobs list?
I need to execute task every 5 minute in ubuntu bash and I like to use windows task scheduler.
I don't know how to write a .bat file to start application in ubuntu bash.
I tested these and did not work.
c:\Windows\System32\bash.exe -l [program_name args]
can run command on ubuntu bash with add -c flag in args
c:\Windows\System32\bash.exe -c <command>
and write it in .bat file and then add to windows task scheduler.
On Windows 8.1.
I have written a simple .sh script to start up my dev environment. I know, I can use Windows native batch script (and it works fine, has no given problem), but I prefer Git Bash. The problem is that every Git Bash window opened by my script is closed on Ctrl+C. And I don't want them to get closed but only exit running processes.
Here is my script. It opens four Git Bash windows and starts processes within them. And when I strike Ctrl+C in one of those four windows, the window just closes. Kills the process (except nginx; nginx continues working) and closes. And I only want to stop the process, not terminate the window:
#!/bin/bash
cd /c/nginx
start sh.exe --login -i -c "nginx"
cd /c/Users/user/app
start sh.exe --login -i -c "NODE_ENV='development' nodemon"
start sh.exe --login -i -c "NODE_ENV='development' gulp mytask"
start sh.exe --login -i -c "NODE_ENV='development' compass watch"
How to do it?
If you use a wrapper like Console2 or ConsoleZ around git bash with it's shell pointed to "C:\Program Files\Git\usr\bin\sh.exe" --login -i or "C:\Windows\SysWOW64\cmd.exe /c ""C:\Program Files\Git\usr\bin\sh.exe" --login -i"" it works fine. I'm not sure how to do it without having that wrapper, but it's pretty cool to use one anyway so you could try it out!
I have the current scenario to deal with:
I have to schedule the backup of my company's Linux-based server (under Suse Linux) with ARCServe R15 (installed on Windows 2003R2SP2).
I know I have the ability in my backup software (ARCServe) to add pre/post execution scripts to my backup-jobs.
If failure of the script, ARCServe would be specified NOT to run the backup-job, and if success, specified to be run. I have no problem with this.
The problem is, I want to make a windows script (to be launched by ARCServe) for executing a Linux script on the cluster:
- If this Linux-script fails, I want my windows-script to fail, so my backup job in ARCServe wouldn't run
- If the Linux-script success, I want my windows-script to end normally with error code 0, so my ARCServe job would run normally.
I've tried creating this batch file (let's call it HPC.bat):
echo ON
start /wait "C:\Program Files\PUTTY\plink.exe" -v -l root -i "C:\IST\admin\scripts\HPC\pri.ppk" [cluster_name] /appli/admin/backup_admin
exit %errorlevel%
If I manually launch this .bat by double-clicking on it, or launching it in a command prompt under Windows, it executes normally and then ends.
If I make it being launched by ARCServe, the script seems never to end.
My job stays in "waiting" status, it seems the execution code of the linux script isn't returned to my batch file, and this one doesn't close.
In my mind, what's happening is plink just opens the connection to the Linux, send the sript execution signal, and then close the connection, so the execution code can't be returned to the batch. Am I right ?
Is what I want to do possible or am I trying something impossible to do ?
So, do I have to proceed differently ?
Do I have to use PUTTY or CygWin instead of plink ?
Please, it's giving me headaches ...
If you install Cygwin, you could do it exactly like you can do it on Linux to Linux, i.e. remotely run a command with ssh someuser#remoteserver.com somecommand
This command will return with the same return code on the calling client, as the command exited with on the remote end. If you use SSH shared keys for authentication instead of passwords, it can also be scripted without user interaction.