This error mainly occurs when executing scripts on the Windows operating system.
To eliminate it, you need to elevate the privileges for the files on which any action will be performed before each command.
Example:
MacOS / Linux:
chmod +x main.py ;
Windows:
absolute_path = "./main.py"
grant_permission_projectSettings_file = `echo "" >> "#{absolute_path}" ; icacls "#{absolute_path}" /grant %USERNAME%:(f,x)`
if grant_permission_projectSettings_file
...
end
Related
I have to zip files on a remote windows machine.
So I first ssh to the windows machine
ssh my_user#my_host "cd /d D:\MyFolder"
And the above command works.
However if I try to run any command after that it fails.
So if I do something like
ssh my_user#my_host "cd /d D:\MyFolder; dir"
The system cannot find the path specified.
You can try something like:
ssh my_user#my_host <<EOF
cd /d D:\MyFolder
dir
EOF
The second EOF should be alone on the line and start from the begin
I am trying to set up a cron on several AWS EC2 machines and would like to run a command on all of them at once, with the following shell script:
#!/bin/sh
cd /etc/cron.daily
touch ecs.sh
echo '#!/bin/sh' > /etc/cron.daily/ecs.sh
echo 'sudo yum update -y ecs-init' >> /etc/cron.daily/ecs.sh
echo 'sudo yum update -y' >> /etc/cron.daily/ecs.sh
sudo chmod 755 /etc/cron.daily/ecs.sh
cd ~
(crontab -u root -l; echo '0 0 * * * /etc/cron.daily/ecs.sh') | crontab -u root -
sudo yum update -y
The part that does not work is: chmod 755 /etc/cron.daily/ecs.sh
I am not sure, what am I missing.
If you can (have sufficient rights to) create a file, you do not need to sudo to change its permissions to 0755. Which would also likely prompt you to input your password and run non-interactively could be the reason why the action did not take place.
On the other hand, if the user running this did not have the necessary (write) permission, preceding lines creating the file would not happen either.
You also do not need to touch a file, because that > redirection will create it (always a new one).
You also should not cd somewhere and and continue performing actions without checking directory was changed as expected. But since on all action but the unnecessary touch you use absolute path names, you can just as well leave out both cd lines.
If you clean-up the script and it still does not perform expected action, it might be useful (assuming non-interactive execution) to save its output (redirect both standard > (or 1>) and error (2>) output to a file) and examine it for errors.
I would like to access existing Windows environment variables such as USERPROFILE from withing the WSL bash prompt. There is information from Microsoft on the use of WSLENV here, and I have tried to work with this:
I added WSLENV as a new System variable within the usual Windows "Environment Variables" control panel, setting it to USERPROFILE/u. I then open Ubuntu from the taskbar, and type:
$ echo $USERPROFILE
...but nothing is returned.
Improved Gábor's answer, since as I've discovered it had a small bug, variables obtained that way contain invisible carriage return character, that could cause unexpected issues latter.
Here is Example:
$ cd /mnt/c/
$ mkdir Windows_NT
$ tmpvar=`/mnt/c/Windows/System32/cmd.exe /C "echo %OS%"`
$ echo $tmpvar
Windows_NT
All seems to be ok, but no:
$ cd $tmpvar
: No such file or directory
This is because tmpvar variable contains additional carriage return character (aka ^M or \r) at the end. We can check this via ls command:
$ ls -ld $tmpvar
ls: cannot access 'Windows_NT'$'\r': No such file or directory
In order to remove that character, output could be be additionally processed with sed or tr:
tmpvar=$(cmd.exe /C echo %OS%|sed $'s/\r$//')
or
tmpvar=$(cmd.exe /C echo %OS%|tr -d '\r')
I've also simplified command a bit. Path /mnt/c/Windows/System32 is already included in $PATH WSL variable by default in recent Windows 10 updates, so just cmd.exe should work.
Now, ls and cd commands work without errors:
$ ls -ld $tmpvar
drwxrwxrwx 1 ubuntu ubuntu 512 Feb 12 05:38 Windows_NT
$ cd $tmpvar
$ pwd
/mnt/c/Windows_NT
pwd command confirms that current directory is correct.
Got a workaround for ya.
$ /mnt/c/Windows/System32/cmd.exe /C "echo %OS%"
Windows_NT
$ tmpvar=`/mnt/c/Windows/System32/cmd.exe /C "echo %OS%"`
$ echo $tmpvar
Windows_NT
I haven't checked WSLENV but the upper one should work. Far from being elegant though.
As this question is from early 2018, my first thought is that the Windows 10 build #user2023370 used was not yet 17063.
Other things to point out:
When setting environment variables from the control panel, make sure that the WSL process is not already running.
Because the USERPROFILE environment variable is a path, you need to add the /p option:
WSLENV=USERPROFILE/up
To test how /p option affects the passed variable, try this in cmd.exe:
Microsoft Windows [Version 10.0.19044.1706]
(c) Microsoft Corporation. All rights reserved.
C:\Users\arttu>set WSLENV=USERPROFILE/up
C:\Users\arttu>wsl
$ echo $USERPROFILE
/mnt/c/Users/arttu
$ exit
logout
C:\Users\arttu>set WSLENV=USERPROFILE/u
C:\Users\arttu>wsl
$ echo $USERPROFILE
C:\Users\arttu
I have a gitlab runner running on a Windows Server 2012 machine.
I have installed win-bash and added the location of the bash executable to the system path.
I have configured the runners config.toml file to use bash for the shell
I have a python script stored on the machine that I need to run as part of the build process. This script is stored on the windows machine and is located at c:\path\to\script.py
The first line in my build script prints the working directory pwd and returns this: /home/gitlab-runner/builds/2b321e5b/0/Firmware/PSoC5LP
My question is this: How do I get access to the C:\ drive?
I am running on a windows machine, and starting bash from any other terminal (cmd.exe, powershell, running the bash.exe directly) puts me into the standard windows directory structure from wherever I start bash:
Microsoft Windows [Version 6.2.9200]
(c) 2012 Microsoft Corporation. All rights reserved.
C:\Users\Administrator\Desktop>bash
bash$ pwd
C:/Users/Administrator/Desktop
bash$ cd /
bash$ pwd
C:/
bash$ cd /home
bash: /home: No such file or directory
bash$ ls
$Recycle.Bin ProgramData
BOOTNXT System Volume Information
Documents and Settings Users
Miniconda2 Windows
Multi-Runner bootmgr
PerfLogs cygwin64
Program Files gitrepos
Program Files (x86) pagefile.sys
bash$
no /home/, not a standard linux directory structure in sight. Because of this, my build scripts fail since they are not able to access the files via there absolute path (I don't even know what their relative paths would look like in the runners bash context)
here is the relevant portion of my build script:
#!/bin/bash
echo "build script executing"
pwd
echo "ls /"
ls /
echo "***assembling the LyteByte asm files"
# move to the LyteByteAssember directory
cd ./LyteByteAssembler/
ASSEMBLY_FILE="LyteByteAssembly.lbasm"
MERGE_FILE="merge.lbasm"
OUTPUT_FILE="../BootloaderProj.cydsn/lytebyte_prog_mem_init.c"
TEMP_DIR="./"
PREPROCESSOR_DIRECTORY="c:/gitrepos/ArcherTools/LyteByteAsembler/LyteBytePreProcessor.py"
echo $PREPROCESSOR_DIRECTORY $ASSEMBLY_FILE $MERGE_FILE $TEMP_DIR
python "$PREPROCESSOR_DIRECTORY" "$ASSEMBLY_FILE" "$MERGE_FILE" "$TEMP_DIR"
if [ $? -eq 0 ]
then
echo "Preprocessing succeeded!"
else
echo "Preprocessing failed, process cancelled"
exit 1
fi
and here is a sample output from the runner:
gitlab-ci-multi-runner 1.1.3 (a470667)
Using Shell executor...
Running on ip-172-31-7-232...
Fetching changes...
HEAD is now at d51e873 hjkj
From https://thing.githost.io/Firmware/PSoC5LP
d51e873..d77e88b CI -> origin/CI
Checking out d77e88b0 as CI...
Previous HEAD position was d51e873... hjkj
HEAD is now at d77e88b... ;jkblkn .,/p
$ bash ./build_script.sh
build script executing
/home/gitlab-runner/builds/2b321e5b/0/Firmware/PSoC5LP
ls /
bin
boot
cgroup
dev
etc
home
lib
lib64
local
lost+found
media
mnt
opt
proc
root
run
sbin
selinux
srv
sys
tmp
usr
var
***assembling the LyteByte asm files
c:/gitrepos/ArcherTools/LyteByteAsembler/LyteBytePreProcessor.py LyteByteAssembly.lbasm merge.lbasm ./
python: can't open file 'c:/gitrepos/ArcherTools/LyteByteAsembler/LyteBytePreProcessor.py': [Errno 2] No such file or directory
Preprocessing failed, process cancelled
It depends on which software you've installed:
If you've installed Git for windows by selecting Git Bash, then you can open Git Bash terminal and browse C: Drive or D: Drive by doing:
cd /c/
cd /c/Windows/
cd /d/
If you've installed cygwin, then you've to do:
cd /cygdrive/c/
Check your manual for win-bash
In order to use rsync I created a BASH script. It runs fine from the Cygwin shell in WIN 7 but fails when run from the WIN 7 Task Scheduler. My Task Scheduler Script is a simple:
c:\cygwin\bin\bash.exe -l -c "~user/rsync_Windows_Backup 2>&1 >> ~user/Documents_cron.log"
The initial directory is set to C:\Cygwin\bin.
My BASH script is a typical rsync command with [options] SRC DEST and some related housekeeping.
The rsync command within the "rsync_Windows_Backup" BASH script is:
/bin/time -f "\nElapse (hh:mm:ss.ss) %E" \
rsync.exe -v -rltz --chmod=a=rw,Da+x -u "$SRC" "$DEST" >> "$LOG" \
2 >> "$LOG"
$ ./rsync_Windows_Backup - succeeds.
But the Task Scheduler Job fails carping that it cannot find the DEST Folder that the BASH script references. When I do a "cd DEST" from the BASH command line the Folder is avialable and can be written to.
I should add some more details that the sender is a WIN 7 desktop that is mapped to a Vista desktop receiver with a drive mapping J:. The BASH script does start but fails with:
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: mkdir "/cygdrive/J/DocumentsBackup" failed: No such file or directory (2) rsync error: error in file IO (code 11)
I have tried several ideas to influence how WIN 7 handles mappings and permissions assuming this is the root of the problem. So far nothing seems to help.
Another characteristic is that the exact same BASH script and Task Scheduler Job does succeed it WIN Vista Business Edition. So I am assuming there is something in WIN 7 that I am missing.
I am stumped and could use some guidance.
Thanks.
I now have this working in Win 7 from the task scheduler as I need. Thank you to #netubsi and #firerat of LinuxQuestionsorg and #konsolebox for the suggestions that lead to a solution.
Here is what I did:
cmd /c net use T: '\\server\share' # Created a separate temporary share for Cygwin
DEST="/cygdrive/T/User/FolderBackup/" # Use temporary Share in Destination
rsync -avuz --copy-links "$SRC" "$DEST" # Do backup
cmd /c net use T: /delete # Remove temporary share
It appears that in WIN 7 the share created in Windows is NOT available to a Cygwin script, IF it is launced from the Win 7 task scheduler. It IS available if the script is launced from the Cygwin command line. It also appears that this is NOT an issue in Win Vista.
This seems odd to me. Perhaps there is another explanation that I am missing. However I am just relieved to have this working!!
You can also just use the network address directly in cygwin:
DEST="//server/share/User/FolderBackup"
Cygwin mounts local and mapped drives under /cygdrive. Using taskscheduler in win7 if you list the contents of /cygdrive, all you will see are local drives???
First option is to run your script as
c:\cygwin\bin\bash.exe -l -c "~/rsync_Windows_Backup >> ~/Documents_cron.log 2>&1"
If you want to capture the stderr output as well, you have to place it in front to copy the fd of the file, and not of stdout.
Make sure that rsync_Windows_Backup has executable permissions. Running ls -l ~/rsync_Windows_Backup should show it.
If it doesn't work, try to use absolute paths. On your Cygwin screen where the current direcory shows ~ in the prompt type pwd which would show something like
User#System ~
$ pwd
/home/User
Basing from that as an example your command should now be like:
c:\cygwin\bin\bash.exe -l -c "/home/User/rsync_Windows_Backup >> /home/User/Documents_cron.log 2>&1"