So I have three installers for NVIDIA's CUDA API -- the first is a driver and comes with nice silent install flag options (but you have to be root and have to have run level 3).
The second two follow are shown manually installing below (cut out the long mess of install afterwards for brevity)
[root]# sh cudatoolkit_4.1.28_linux_64_rhel5.x.run Verifying archive
integrity... All good. Uncompressing NVIDIA
CUDA.............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Enter install path (default /usr/local/cuda, '/cuda' will be
appended): A previous version of CUDA was found in /usr/local/cuda/bin
Would you like to uninstall? (yes/no/abort): yes
In other words, I need to recognize:
"Enter install path" and output a '\n'
Now the tricky part is the uninstall may not be always be there. If it's not I need to simply wait for the install to finish, but if I see "Would you like to uninstall?" I need to output "yes" to complete.
The third and final installer's output is shown below....
[root]# sh gpucomputingsdk_4.1.28_linux.run Verifying archive
integrity... All good. Uncompressing NVIDIA GPU Computing
SDK............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Enter install path (default ~/NVIDIA_GPU_Computing_SDK):
/usr/local/CUDA_SDK Located CUDA at /usr/local/cuda If
this is correct, choose the default below. If it is not correct,
enter the correct path to CUDA Enter CUDA install path
(default /usr/local/cuda):
For this one, there is no uninstall action so it's seemingly a bit simpler.
I just need to detect "Enter install path" and output "/usr/local/CUDA_SDK\n" and then detect "Enter CUDA install path" and output "\n"
My idea was to use a pair of expect scripts -- one for each installer -- but due to the nesting within the double quotes of the command to switch to root, I'm having some difficulties with this. What I currently have is:
#!/bin/bash
CR="\"\n\""
YES="\"Yes\""
INSTALL_PATH_REQUEST="\"Enter install path\""
CUDA_PATH_REQUEST="\"Enter CUDA install path\""
UNINSTALL_REQUEST="\"Would you like to uninstall?\""
TOOLKIT=`ls -t cudatoolkit* | head -n 1`
TOOLKIT_EXPECT="sh $TOOLKIT"
SDK=`ls -t gpucomputingsdk* | head -n 1`
SDK_INSTALL_PATH="\"/usr/local/CUDA_SDK\n\""
SDK_EXPECT="sh $SDK"
/bin/su root -c "yum -q -y install expect expectk;
/sbin/init 3; sh `ls -t NVIDIA*|head -n 1` -s --update -a -X;
/usr/bin/expect <<EOF;
spawn $TOOLKIT_EXPECT
expect $INSTALL_PATH_REQUEST
send $CR
expect $UNINSTALL_REQUEST
send $YES
EOF
/usr/bin/expect <<EOF;
spawn $SDK_EXPECT
expect $INSTALL_PATH_REQUEST
send $SDK_INSTALL_PATH
expect $CUDA_PATH_REQUEST
send $CR
EOF
/sbin/init 5"
This switches to root properly (once the password is entered) and installs the driver with the built in options correctly. It then appears to spawn the second install process and enter the first argument (a carriage return), but seems to exit the second installer prematurely (e.g. I don't see the "yes" option.).
I feel like I'm pretty close, hopefully somebody can point me to where I'm going wrong and suggest the correct syntax.
NOTES:
I added the yum install command, as some of the machines I'm installing on didn't have expect (stock CentOS 6), so that saves me the trouble there....
Might be an issue with timeout here... not sure how long the installer takes.
The default expect timeout is 10 seconds, if it doesn't see the expected text in that time, it will proceed regardless, you could change the timeout values like so:
expect -timeout 100 $INSTALL_PATH_REQUEST
Also change your $YES from
YES="\"Yes\""
To:
YES="\"Yes\r\""
(Best to use \r instead of \n in $CR too)
It's also a good idea to expect some 'safety string' at the end of the install, for example:
expect -timeout 320 "Install Complete."
So the expect script doesn't terminate before the spawned process is complete.
I manipulate dozens of bash scripts in which I'm likely to change options. Changing the options involves three operations :
Changing the string you provide to getopts to parse options (:g:h:pt for example)
Write the piece of code to affect arguments (opt1=$OPTARG)
Changing the usage function (the function which displays a description of the description)
This is a bit heavy, especially when you know that boost::program_options provide a nice interface to handle options in C++.
Is there something similar to boost::program_options in Bash ?
Use argbash. You won't regret it.
Argbash documentation
Argbash uses getopts in the background, but manages most of the implementation for you and provides a more consistent parsing codebase across projects. I've used it successfully, and its awesome, but does have a learning curve. Its a code generator that creates a parser script that supports long and short options, and creates help documentation automatically. It will even help with man pages.
The basic steps are:
Install argbash. You can use the install instructions on site to compile, but I recommend using Docker container
create a template m4 file, defining your options. You can do this manually or create a script.
If you are using the docker container, it would be something like:
argbash-init-docker \
--opt myoption1 \
--opt-bool myoption2 \
--pos my_arg1 \
--pos my_arg2 \
parser.m4
Run argbash with the template you generated as an input.
Something like:
argbash-docker \
parser.m4 \
--strip user-content \
-o parser.sh
In your main script that will be using the parser, source the parser.sh script from the output of the previous command
source ./parser.sh
Reference the options in your code
An example of how you'd reference a boolean option:
if test $_arg_myoption2 = on;then
echo 'myoption2 is on'
fi
Test
./my-script.sh --myoption2 arg1 arg2
repeat
As for your concern of manual steps, argbash allows you to keep it to a minimum. You can get it to a point that you are just updating the template and running a build script.My current implementation does have more manual steps than I'd like, but I'll be automating them out soon.
I have a more detailed outline of how I use it in my project here README-Argbash, and you can look at my code to see how I use it in the main script.
Option 2 - Use docopts , the docopt implementation for Bash.
The downside of the docopts is that it requires the docopt interpreter to be separately distributed to each user of your cli. This is a no-go for me. As a side note, Argbash can generate a docopt compliant help documentation to be used as the docopt template.
Use getoptions.
https://github.com/ko1nksm/getoptions
getoptions is a new option parser (generator) written in POSIX-compliant shell scripts for those who want to support POSIX and GNU standard option syntax in your shell scripts (dash, bash, ksh, zsh and all POSIX shells).
It is fast and small, while supporting abbreviated long options, subcommands, automatic help generation, etc. And it is very easy to use because it is implemented with pure shell functions and does not require any other tools.
It is also an option parser generator. Pre-generating the option parser code eliminates the need for including the libraries and makes it even faster.
Example (this is all):
#!/bin/sh
VERSION=1.0
parser_definition() {
setup REST help:usage abbr:true -- "Usage: example.sh [options] [arguments]" ''
msg -- "Options:"
flag FLAG_A -a
flag FLAG_B -b
flag FLAG -f +f --{no-}flag -- "takes no arguments"
param PARAM -p --param -- "takes one argument"
option OPTION -o --option on:"default" -- "takes no arguments or one argument"
disp :usage -h --help
disp VERSION --version
}
eval "$(getoptions parser_definition) exit 1"
echo "FLAG: $FLAG, PARAM: $PARAM, OPTION: $OPTION"
printf ': %s\n' "$#" # Rest arguments
script.sh -ab -f +f --flag --no-flag -p 1 -p2 --param 3 --param=4 --option=5 --op -- A B
Question
How can one specify a user's emacs init file to load with emacsclient?
emacsclient does not understand '-u user' and '-a ALTERNATE-EDITOR' does not allow me to quote it and provide '-u user'.
For example, running:
/usr/bin/emacsclient -n -a '/usr/bin/emacs -u <username>' ~<username>/notes.txt
returns
/usr/bin/emacsclient: error executing alternate editor "/usr/bin/emacs -u <username>"
Background
I'm using emacs version 23.1.1 and emacsclient version 23.1.
emacs itself supports '-u user' to load a specified user's init file.
I use the following bash function in my aliases file to invoke emacs
# a wrapper is needed to sandwich multiple command line arguments in bash
# 2>/dev/null hides
# "emacsclient: can't find socket; have you started the server?"
emacs_wrapper () {
if [ 0 -eq $# ]
then
/usr/bin/emacsclient -n -a /usr/bin/emacs ~<username>/notes.txt 2>/dev/null &
else
/usr/bin/emacsclient -n -a /usr/bin/emacs $* 2>/dev/null &
fi
}
alias x='emacs_wrapper'
Typing x followed by a list of files:
Connects to an existing emacs server if one is running, otherwise starts a new one
Executes as a background process
Opens the list of files or my notes file if no files are provided
This works great when I'm logged in as myself. However, many production boxes require me to log in as a production user. I've separated my aliases into a bash script, therefore I can get my aliases and bash functions by simply running.
. ~<username>/alias.sh
Unfortunately, this won't let me use my .emacs file (~<username>/.emacs) :(
This problem has been driving me crazy.
If you can't include command line arguments in your alternate editor specification, then simply write a shell script which does that for you, and supply that as the alternate editor argument instead.
#!/bin/sh
emacs -u (username) "$#"
The point of the server/client model is that you have an existing Emacs with its own set of configurations, and then you connect via one or more clients.
What should the client do if the server was already configured to show the menu bar (a global setting), and the client says not to show it? What if another client attaches saying to show it?
If you want to use different settings for Emacs, use different emacs sessions.
My application does cyclic error_logger reports.
These will be displayed on the Erlang shell which is quite a lot of output.
This makes typing into the shell quite a nuisance.
What is the usual way of dealing with this given that:
I really want to see this output
I'd don't like it all over the input line I just type
How to deal with this? Always have distribution on and connect with a second shell for user input (this is extra effort when starting the application, which I do often during development).
I'd prefer some automatic easily startable setup where all logging and sasl messages go one place and my input and return values is undisturbed in another place.
For reference this is how I start my sessions:
#!/bin sh
erl +W w -boot start_sasl -config myapp -s myapp -extra "$#"
In the docs for the kernel ( http://erlang.org/doc/man/kernel_app.html ) it described how to set your application environment variables to redirect error_logger printouts to a file or disable them completely. Something like this should work for you:
erl +W w -boot start_sasl -kernel error_logger '{file,"/tmp/log"}' -config myapp -s myapp -extra "$#"
there are also similar options which you can use for sasl printouts: http://erlang.org/doc/man/sasl_app.html
I'm trying to run a bash script in Cygwin.
I get Must run as root, i.e. sudo ./scriptname errors.
chmod 777 scriptname does nothing to help.
I've looked for ways to imitate sudo on Cygwin, to add a root user, since calling "su" renders the error su: user root does not exist, anything useful, and have found nothing.
Anyone have any suggestions?
I answered this question on SuperUser but only after the OP disregarded the unhelpful answer that was at the time the only answer to the question.
Here is the proper way to elevate permissions in Cygwin, copied from my own answer on SuperUser:
I found the answer on the Cygwin mailing list. To run command with elevated privileges in Cygwin, precede the command with cygstart --action=runas like this:
$ cygstart --action=runas command
This will open a Windows dialogue box asking for the Admin password and run the command if the proper password is entered.
This is easily scripted, so long as ~/bin is in your path. Create a file ~/bin/sudo with the following content:
#!/usr/bin/bash
cygstart --action=runas "$#"
Now make the file executable:
$ chmod +x ~/bin/sudo
Now you can run commands with real elevated privileges:
$ sudo elevatedCommand
You may need to add ~/bin to your path. You can run the following command on the Cygwin CLI, or add it to ~/.bashrc:
$ PATH=$HOME/bin:$PATH
Tested on 64-bit Windows 8.
You could also instead of above steps add an alias for this command to ~/.bashrc:
# alias to simulate sudo
alias sudo='cygstart --action=runas'
You probably need to run the cygwin shell as Administrator. You can right click the shortcut and click run as administrator or go into the properties of the shortcut and check it in the compatability section. Just beware.... root permissions can be dangerous.
Building on dotancohen's answer I'm using an alias:
alias sudo="cygstart --action=runas"
Works as a charm:
sudo chown User:Group <file>
And if you have SysInternals installed you can even start a command shell as the system user very easily
sudo psexec -i -s -d cmd
I found sudo-for-cygwin, maybe this would work, it is a client/server application that uses a python script to spawn a child process in windows (pty) and bridges user's tty and the process I/O.
It requires python in windows and Python modules greenlet, and eventlet in Cygwin.
It seems that cygstart/runas does not properly handle "$#" and thus commands that have arguments containing spaces (and perhaps other shell meta-characters -- I didn't check) will not work correctly.
I decided to just write a small sudo script that works by writing a temporary script that does the parameters correctly.
#! /bin/bash
# If already admin, just run the command in-line.
# This works on my Win10 machine; dunno about others.
if id -G | grep -q ' 544 '; then
"$#"
exit $?
fi
# cygstart/runas doesn't handle arguments with spaces correctly so create
# a script that will do so properly.
tmpfile=$(mktemp /tmp/sudo.XXXXXX)
echo "#! /bin/bash" >>$tmpfile
echo "export PATH=\"$PATH\"" >>$tmpfile
echo "$1 \\" >>$tmpfile
shift
for arg in "$#"; do
qarg=`echo "$arg" | sed -e "s/'/'\\\\\''/g"`
echo " '$qarg' \\" >>$tmpfile
done
echo >>$tmpfile
# cygstart opens a new window which vanishes as soon as the command is complete.
# Give the user a chance to see the output.
echo "echo -ne '\n$0: press <enter> to close window... '" >>$tmpfile
echo "read enter" >>$tmpfile
# Clean up after ourselves.
echo "rm -f $tmpfile" >>$tmpfile
# Do it as Administrator.
cygstart --action=runas /bin/bash $tmpfile
Or install syswin package, which includes a port of su for cygwin: http://sourceforge.net/p/manufacture/wiki/syswin-su/
This answer is based off of another answer. First of all, make sure your account is in the Administrators group.
Next, create a generic "runas-admin.bat" file with the following content:
#if (1==1) #if(1==0) #ELSE
#echo off&SETLOCAL ENABLEEXTENSIONS
>nul 2>&1 "%SYSTEMROOT%\system32\cacls.exe" "%SYSTEMROOT%\system32\config\system"||(
cscript //E:JScript //nologo "%~f0" %*
#goto :EOF
)
FOR %%A IN (%*) DO (
"%%A"
)
#goto :EOF
#end #ELSE
args = WScript.Arguments;
newargs = "";
for (var i = 0; i < args.length; i++) {
newargs += "\"" + args(i) + "\" ";
}
ShA=new ActiveXObject("Shell.Application");
ShA.ShellExecute("cmd.exe","/c \""+WScript.ScriptFullName+" "+newargs+"\"","","runas",5);
#end
Then execute the batch file like this:
./runas-admin.bat "<command1> [parm1, parm2, ...]" "<command2> [parm1, parm2, ...]"
For exaxmple:
./runas-admin.bat "net localgroup newgroup1 /add" "net localgroup newgroup2 /add"
Just make sure to enclose each separate command in double quotes. You will only get the UAC prompt once using this method and this procedure has been generalized so you could use any kind of command.
A new proposal to enhance SUDO for CygWin from GitHub in this thread, named TOUACExt:
Automatically opens sudoserver.py.
Automatically closes sudoserver.py after timeout (15 minutes default).
Request UAC elevation prompt Yes/No style for admin users.
Request Admin user/password for non-admin users.
Works remotely (SSH) with admin accounts.
Creates log.
Still in Pre-Beta, but seems to be working.
I landed here through google, and I actually believe I've found a way to gain a fully functioning root promt in cygwin.
Here are my steps.
First you need to rename the Windows Administrator account to "root"
Do this by opening start manu and typing "gpedit.msc"
Edit the entry under
Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Accounts: Rename administrator account
Then you'll have to enable the account if it isn't yet enabled.
Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Accounts: Administrator account status
Now log out and log into the root account.
Now set an environment variable for cygwin. To do that the easy way:
Right Click My Computer > Properties
Click (on the left sidebar) "Advanced system settings"
Near the bottom click the "Enviroment Variables" button
Under "System Variables" click the "New..." button
For the name put "cygwin" without the quotes.
For the value, enter in your cygwin root directory. ( Mine was C:\cygwin )
Press OK and close all of that to get back to the desktop.
Open a Cygwin terminal (cygwin.bat)
Edit the file /etc/passwd
and change the line
Administrator:unused:500:503:U-MACHINE\Administrator,S-1-5-21-12345678-1234567890-1234567890-500:/home/Administrator:/bin/bash
To this (your numbers, and machine name will be different, just make sure you change the highlighted numbers to 0!)
root:unused:0:0:U-MACHINE\root,S-1-5-21-12345678-1234567890-1234567890-0:/root:/bin/bash
Now that all that is finished, this next bit will make the "su" command work. (Not perfectly, but it will function enough to use. I don't think scripts will function correctly, but hey, you got this far, maybe you can find the way. And please share)
Run this command in cygwin to finalize the deal.
mv /bin/su.exe /bin/_su.exe_backup
cat > /bin/su.bat << "EOF"
#ECHO OFF
RUNAS /savecred /user:root %cygwin%\cygwin.bat
EOF
ln -s /bin/su.bat /bin/su
echo ''
echo 'All finished'
Log out of the root account and back into your normal windows user account.
After all of that, run the new "su.bat" manually by double clicking it in explorer. Enter in your password and go ahead and close the window.
Now try running the su command from cygwin and see if everything worked out alright.
Being unhappy with the available solution, I adopted nu774's script to add security and make it easier to setup and use. The project is available on Github
To use it, just download cygwin-sudo.py and run it via python3 cygwin-sudo.py **yourcommand**.
You can set up an alias for convenience:
alias sudo="python3 /path-to-cygwin-sudo/cygwin-sudo.py"
Use this to get an admin window with either bash or cmd running, from any directories context menue. Just right click on a directory name, and select the entry or hit the highlited button.
This is based on the chere tool and the unfortunately not working answer (for me) from link_boy. It works fine for me using Windows 8,
A side effect is the different color in the admin cmd window. To use this on bash, you can change the .bashrc file of the admin user.
I coudln't get the "background" version (right click into an open directory) to run. Feel free to add it.
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Directory\shell\cygwin_bash]
#="&Bash Prompt Here"
"Icon"="C:\\cygwin\\Cygwin.ico"
[HKEY_CLASSES_ROOT\Directory\shell\cygwin_bash\command]
#="C:\\cygwin\\bin\\bash -c \"/bin/xhere /bin/bash.exe '%L'\""
[HKEY_CLASSES_ROOT\Directory\shell\cygwin_bash_root]
#="&Root Bash Prompt Here"
"Icon"="C:\\cygwin\\Cygwin.ico"
"HasLUAShield"=""
[HKEY_CLASSES_ROOT\Directory\shell\cygwin_bash_root\command]
#="runas /savecred /user:administrator \"C:\\cygwin\\bin\\bash -c \\\"/bin/xhere /bin/bash.exe '%L'\\\"\""
[HKEY_CLASSES_ROOT\Directory\shell\cygwin_cmd]
#="&Command Prompt Here"
[HKEY_CLASSES_ROOT\Directory\shell\cygwin_cmd\command]
#="cmd.exe /k cd %L"
"HasLUAShield"=""
[HKEY_CLASSES_ROOT\Directory\shell\cygwin_cmd_root]
#="Roo&t Command Prompt Here"
"HasLUAShield"=""
[HKEY_CLASSES_ROOT\Directory\shell\cygwin_cmd_root\command]
#="runas /savecred /user:administrator \"cmd.exe /t:1E /k cd %L\""
A very simple way to have a cygwin shell and corresponding subshells to operate with administrator privileges is to change the properties of the link which opens the initial shell.
The following is valid for Windows 7+ (perhaps for previous versions too, but I've not checked)
I usually start the cygwin shell from a cygwin-link in the start button (or desktop).
Then, I changed the properties of the cygwin-link in the tabs
/Compatibility/Privilege Level/
and checked the box,
"Run this program as an administrator"
This allows the cygwin shell to open with administrator privileges and the corresponding subshells too.
I met this discussion looking for some details on the sudo implementation in different operating systems. Reading it I found that the solution by #brian-white (https://stackoverflow.com/a/42956057/3627676) is useful but can be improved slightly. I avoided creating the temporary file and implemented to execute everything by the single script.
Also I investigated the next step of the improvement to output within the single window/console. Unfortunately, without any success. I tried to use named pipes to capture STDOUT/STDERR and print in the main window. But child process didn't write to named pipes. However writing to a regular file works well.
I dropped any attempts to find the root cause and left the current solution as is. Hope my post can be useful as well.
Improvements:
no temporary file
no parsing and reconstructing the command line options
wait the elevated command
use mintty or bash, if the first one not found
return the command exit code
#!/bin/bash
# Being Administrators, invoke the command directly
id -G | grep -qw 544 && {
"$#"
exit $?
}
# The CYG_SUDO variable is used to control the command invocation
[ -z "$CYG_SUDO" ] && {
mintty="$( which mintty 2>/dev/null )"
export CYG_SUDO="$$"
cygstart --wait --action=runas $mintty /bin/bash "$0" "$#"
exit $?
}
# Now we are able to:
# -- launch the command
# -- display the message
# -- return the exit code
"$#"
RETVAL=$?
echo "$0: Press to close window..."
read
exit $RETVAL
Based on #mat-khor's answer, I took the syswin su.exe, saved it as manufacture-syswin-su.exe, and wrote this wrapper script. It handles redirection of the command's stdout and stderr, so it can be used in a pipe, etc. Also, the script exits with the status of the given command.
Limitations:
The syswin-su options are currently hardcoded to use the current user. Prepending env USERNAME=... to the script invocation overrides it. If other options were needed, the script would have to distinguish between syswin-su and command arguments, e.g. splitting at the first --.
If the UAC prompt is cancelled or declined, the script hangs.
.
#!/bin/bash
set -e
# join command $# into a single string with quoting (required for syswin-su)
cmd=$( ( set -x; set -- "$#"; ) 2>&1 | perl -nle 'print $1 if /\bset -- (.*)/' )
tmpDir=$(mktemp -t -d -- "$(basename "$0")_$(date '+%Y%m%dT%H%M%S')_XXX")
mkfifo -- "$tmpDir/out"
mkfifo -- "$tmpDir/err"
cat >> "$tmpDir/script" <<-SCRIPT
#!/bin/env bash
$cmd > '$tmpDir/out' 2> '$tmpDir/err'
echo \$? > '$tmpDir/status'
SCRIPT
chmod 700 -- "$tmpDir/script"
manufacture-syswin-su -s bash -u "$USERNAME" -m -c "cygstart --showminimized bash -c '$tmpDir/script'" > /dev/null &
cat -- "$tmpDir/err" >&2 &
cat -- "$tmpDir/out"
wait $!
exit $(<"$tmpDir/status")
Can't fully test this myself, I don't have a suitable script to try it out on, and I'm no Linux expert, but you might be able to hack something close enough.
I've tried these steps out, and they 'seem' to work, but don't know if it will suffice for your needs.
To get round the lack of a 'root' user:
Create a user on the LOCAL windows machine called 'root', make it a member of the 'Administrators' group
Mark the bin/bash.exe as 'Run as administrator' for all users (obviously you will have to turn this on/off as and when you need it)
Hold down the left shift button in windows explorer while right clicking on the Cygwin.bat file
Select 'Run as a different user'
Enter .\root as the username and then your password.
This then runs you as a user called 'root' in cygwin, which coupled with the 'Run as administrator' on the bash.exe file might be enough.
However you still need a sudo.
I faked this (and someone else with more linux knowledge can probably fake it better) by creating a file called 'sudo' in /bin and using this command line to send the command to su instead:
su -c "$*"
The command line 'sudo vim' and others seem to work ok for me, so you might want to try it out.
Be interested to know if this works for your needs or not.
What I usually do is have a registry "Open Here" helper in order to open a cygwin shell with administrative privileges quite easy from anywhere in my computer.
Be aware you have to have the cygwin "chere" package installed, use "chere -i -m" from an elevated cygwin shell first.
Assuming your cygwin installation is in C:\cygwin...
Here's the registry code:
Windows Registry Editor Version 5.00
[-HKEY_CLASSES_ROOT\Directory\shell\cygwin_bash]
[HKEY_CLASSES_ROOT\Directory\shell\cygwin_bash]
#="Open Cygwin Here as Root"
"HasLUAShield"=""
[HKEY_CLASSES_ROOT\Directory\shell\cygwin_bash\command]
#="c:\\cygwin\\bin\\mintty.exe -i /Cygwin-Terminal.ico -e /bin/xhere /bin/bash.exe"
[-HKEY_CLASSES_ROOT\Directory\Background\shell\cygwin_bash]
[HKEY_CLASSES_ROOT\Directory\Background\shell\cygwin_bash]
#="Open Cygwin Here as Root"
"HasLUAShield"=""
[HKEY_CLASSES_ROOT\Directory\Background\shell\cygwin_bash\command]
#="c:\\cygwin\\bin\\mintty.exe -i /Cygwin-Terminal.ico -e /bin/xhere /bin/bash.exe"
[-HKEY_CLASSES_ROOT\Drive\shell\cygwin_bash]
[HKEY_CLASSES_ROOT\Drive\shell\cygwin_bash]
#="Open Cygwin Here as Root"
"HasLUAShield"=""
[HKEY_CLASSES_ROOT\Drive\shell\cygwin_bash\command]
#="c:\\cygwin\\bin\\mintty.exe -i /Cygwin-Terminal.ico -e /bin/xhere /bin/bash.exe"
Hope this helps. Let me know if it works for you. Thanks.
PS: You can grab this code, copy and paste it and save it in a name.reg file to run it... or you can manually add the values.
Just simplifying the accepted answer, copy past the below in a Cygwin terminal and you are done:
cat <<EOF >> /bin/sudo
#!/usr/bin/bash
cygstart --action=runas "\$#"
EOF
chmod +x /bin/sudo
Try:
chmod -R ug+rwx <dir>
where <dir> is the directory on which you
want to change permissions.