After installing anaconda3 in windows, I can run python commands from the anaconda prompt, but not from the windows command prompt.
I would like to make a desktop shortcut to activate my environment and run spyder from it. Previously, I would do this with a .bat file, but now that I cannot run python commands from cmd.exe this doesn't work.
Is there an alternative way of running batch files for the anaconda prompt?
I know that I could just modify my PATH to get cmd.exe to run python commands, but I'd like to avoid this if possible.
I believe all the Anaconda prompt does is open CMD and run a batch file. Make the first command of your script:
call <anaconda_dir>/Scripts/activate.bat <anaconda_dir>
Extending Jeremy's answer:
You do need to use call for the "activate.bat" script as well as any subsequent Anaconda/Python-related commands. Otherwise the prompt will immediately quit after running the commands, even if you use a pause statement. Please see below example:
set root=C:\Users\john.doe\AppData\Local\Continuum\anaconda3
call %root%\Scripts\activate.bat %root%
call conda list pandas
pause
Thanks to this thread I solved my challenge to get a windows batch file to open the Ananconda Prompt and then run some python code.
Here is the batch file:
#echo on
call C:\ProgramData\Anaconda3\Scripts\activate.bat
C:\ProgramData\Anaconda3\python.exe "D:\Documents\PythonCode\TFLAPI\V1.py"
Add
call "<anaconda_dir>\Scripts\activate.bat"
to the start of your script (it doesn't actually require an argument, and it activates the base environment by default).
Note that after this line, you can make use of the CONDA_ envvars!
For Windows, use the following script in your batch file to execute a Python script. Simply change your personal file paths like this:
cmd /c C:\ProgramData\Anaconda3\condabin\conda.bat run "C:\ProgramData\Anaconda3\python.exe" "C:\Users\User Name\Path to your Python File\Python File.py"
The easiest way to execute anaconda scripts through .bat
set venv=name_of_virtual_env
call %USERPROFILE%\Anaconda3\Scripts\activate %USERPROFILE%\Anaconda3
call activate %venv%
:: Change directory to the relative path that's needed for script
cd %~dp0
:: Run script at this location
call %USERPROFILE%/Anaconda3/envs/%venv%/python.exe "%~dp0\main.py"
PAUSE
%USERPROFILE% == C:\Users\name
%~dp == C:\Users\name\path\to\Project\RUN.bat
"%~dp0\main.py" == path to run targeted script
Powershell Version:
$qtconsole="C:\Users\<YourUserName>\.anaconda\navigator\scripts\qtconsole.bat"
start-process $qtconsole -WindowStyle Hidden
Note: this script will only start one instance of the qtconsole at a time due to DLL limitations of Linux QT GUI library only supporting one instance of the same exe running at the same time. That's probably why they use "Anaconda Navigator" to launch the QtConsole programs to get around this restriction.
As an alternative to the above solution if you are having windows os. You can use git bash
you need to add the path to conda.sh to you .bash_profile or whatever it is named to be able to run conda commands. here is an example:
echo ". C:/Users/user/Anaconda3/etc/profile.d/conda.sh" >> ~/.bash_profile
Run your script => . script.sh
It would be a good alternative too.
Check this and this for more details.
Hope it will help someone :).
Extending #N4v answer as this is the only approach that worked for me in calling the Python script. Python version is 3.7
set root=C:\Users\xxxx\Anaconda3 #Anaconda default folder on my computer
set env1=C:\Users\xxxx\Anaconda3\envs\py37 #My Python environment folder. The name I gave is py37. Can be specific to yours
call %root%\Scripts\activate.bat %env1% #Call command to activate py37 environment.
python "C:\Path to the folder with python file\Pythonfile.py" #Run the file of interest after running python specific to the called environment. Replace this with your files path and name.
pause
Based on the answer of #ivan_pozdeev I found the following to be the cleanest solution for me:
#ECHO OFF
CALL "<anaconda_dir>\Scripts\activate.bat" [<conda_environment_if_not_base>]
%CONDA_PYTHON_EXE% "<full_path_to_your_python_script>" %1 %2 %3 %4 %5 %6 %7 %8 %9
conda deactivate
So for example:
#ECHO OFF
CALL "E:\ProgramData\Anaconda3\Scripts\activate.bat"
%CONDA_PYTHON_EXE% "C:\Users\<user>\Documents\Python3\my_project\src\my_script.py" %1 %2 %3 %4 %5 %6 %7 %8 %9
conda deactivate
By including conda deactivate at the end of the batch file you leave the commandline in the state you started. And if you need a different conda environment you can specify this after activate.bat.
Perform the following steps:
call "C:\Users\yourname\anaconda3\condabin\activate.bat"
cd "Your\program\path"
call activate your_env
python main.py
call conda deactivate
Refer to this article:
https://medium.com/#roddyjaques/how-to-run-anaconda-programs-with-a-bat-file-5f6dd7675508
Related
The Anaconda command prompt looks like normal windows command prompt and its start menu shortcut traces back to the cmd.exe file on windows in the C:\Windows\System32 directory, so I know it is just an instance of the command prompt with certain other characteristics or features. I am curious as to what all these other aspects are.
When I click on properties of the "Anaconda Prompt" shortcut, the target is "%windir%\System32\cmd.exe" /K" C:\ProgramData\Anaconda3\Scripts\activate.bat C:\ProgramData\Anaconda3 so it has some extra arguments. In those arguments is the difference between opening a vanilla command prompt and an Anaconda.
Breaking down these commands, the /k option appears to be described here and here to mean run the command and return to the prompt, although those references refer to a lower case /k.
The next argument points to a bat file to activate an Anaconda script. Then it passes a path to a directory called "Anaconda3". I am fairly certain the path it passes as the final arg means it wants this path to be accessible as if it were in the user or system path environmental variable. Python.exe (Python 3) is in this directory, as well as a _conda.exe and an important Scripts folder, so if we don't have our python in the system or user path, this is how it is found, I am fairly certain.
Back to the .bat file, this does a lot of things. I always though bats were binaries, because of how they acted on the system, but they're really just like Bash Scripts for Windows. They are human readable and mine is as follows:
#set "_args1=%1"
#set _args1_first=%_args1:~0,1%
#set _args1_last=%_args1:~-1%
#set _args1_first=%_args1_first:"=+%
#set _args1_last=%_args1_last:"=+%
#set _args1=
#if "%_args1_first%"=="+" if NOT "%_args1_last%"=="+" (
#CALL "%~dp0..\condabin\conda.bat" activate
#GOTO :End
)
#REM This may work if there are spaces in anything in %*
#CALL "%~dp0..\condabin\conda.bat" activate %*
:End
#set _args1_first=
#set _args1_last=
This .bat calls another .bat, "conda.bat", in a nearby directory with it's own code:
#IF NOT DEFINED _CE_CONDA (
#SET _CE_M=
#SET "CONDA_EXE=%~dp0..\Scripts\conda.exe"
)
#IF [%1]==[activate] "%~dp0_conda_activate" %*
#IF [%1]==[deactivate] "%~dp0_conda_activate" %*
#SETLOCAL EnableDelayedExpansion
#IF DEFINED _CE_CONDA (
#REM when _CE_CONDA is defined, we're in develop mode. CONDA_EXE is actually python.exe in the root of the dev env.
FOR %%A IN ("%CONDA_EXE%") DO #SET _sysp=%%~dpA
) ELSE (
#REM This is the standard user case. This script is run in root\condabin.
FOR %%A IN ("%~dp0.") DO #SET _sysp=%%~dpA
IF NOT EXIST "!_sysp!\Scripts\conda.exe" #SET "_sysp=!_sysp!..\"
)
#SET _sysp=!_sysp:~0,-1!
#SET PATH=!_sysp!;!_sysp!\Library\mingw-w64\bin;!_sysp!\Library\usr\bin;!_sysp!\Library\bin;!_sysp!\Scripts;!_sysp!\bin;%PATH%
#SET CONDA_EXES="%CONDA_EXE%" %_CE_M% %_CE_CONDA%
#CALL %CONDA_EXES% %*
#ENDLOCAL
#IF %errorlevel% NEQ 0 EXIT /B %errorlevel%
#IF [%1]==[install] "%~dp0_conda_activate" reactivate
#IF [%1]==[update] "%~dp0_conda_activate" reactivate
#IF [%1]==[upgrade] "%~dp0_conda_activate" reactivate
#IF [%1]==[remove] "%~dp0_conda_activate" reactivate
#IF [%1]==[uninstall] "%~dp0_conda_activate" reactivate
#EXIT /B %errorlevel%
As I expected, when I called the activate.bat file in an ordinary (admin) command prompt, it turned into an Anaconda prompt with the "(base)" prefix before my current path you get when you click the startup shortcut. (base) C:\Users\User>. Interestingly, doing this only seems to work in the regular command prompt, not Git Bash, not WSL, not even Powershell, though there is a separate Powershell launcher that works. In its properties, it has the target:
%windir%\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy ByPass -NoExit -Command "& 'C:\ProgramData\Anaconda3\shell\condabin\conda-hook.ps1' ; conda activate 'C:\ProgramData\Anaconda3' "
And if you run the ps1 file (a powershell like script), it has the same effect of putting you into the conda environment, because you can run the 'conda' command and help instructions appear.
Here is the ps1 code.
$Env:CONDA_EXE = "C:/ProgramData/Anaconda3\Scripts\conda.exe"
$Env:_CE_M = ""
$Env:_CE_CONDA = ""
$Env:_CONDA_ROOT = "C:/ProgramData/Anaconda3"
$Env:_CONDA_EXE = "C:/ProgramData/Anaconda3\Scripts\conda.exe"
Import-Module "$Env:_CONDA_ROOT\shell\condabin\Conda.psm1"
Add-CondaEnvironmentToPrompt
Anyway that's just kind of the background context, which I learned in the last few hour researching, because I wanted to do my homework. I wanted and want to know is what Conda is doing in Windows when you open the Command Prompt through Anaconda. I'm pretty certain it is doing two main things: setting the path to include the C:\ProgramData\Anaconda3 directory, for the session, and activating it's base environment or any other virtual environment you tell it to launch that you may have created through it at some point, but does it do anything else of note?
I ask this not just because I am curious about what's really going on (I am), but I was also hoping to work with Conda in Git Bash and WSL, terminals I really like. I can currently use Conda's Python with them (the only Python on my machine) as it seems to exist independent of the program that installed it and manages packages for it, but I was specifically hoping to use the all the Conda environment management tools inside Git Bash or WSL. After thinking about it, I now don't believe this is possible. From a naive user perspective, one sort of assumes they can run any program anywhere, and that makes sense or would have made sense before we had sub-systems and systems within systems, but from a more aware point of view, Anaconda was installed for Windows and inside the C:\ProgramData\Anaconda3 directory are .exe and .bat files, not Linux/WSL compatible binaries and .sh or .bash files. It's like trying to run Windows_OS>Linux subsystem>Windows_file_again, but it doesn't work like that. WSL and Git Bash don't even have the same path structure somehow. Am I right in my thinking so far?
I enjoy Git Bash and WSL more than Powershell or cmd and I use them a lot for GCC and git. I do most of my coding in VS Code and launch these terminals there. I suppose at best I could install conda for git bash or wsl if such a thing existed, but even then it might not be able to talk to my main Conda or share environments. Otherwise I could either trying using venv for an environment, as that appears to work in these shells through python, or just use the normal command prompt to do everything if I really want to use Conda.
Am I right in my assessments?
Thanks for sticking with me! To get good at something, you have to get to the point where it's all plainly obvious, otherwise you run the risk of being lost and confused at a time you least want to be.
Edit: Now that I'm back at it, I rediscovered my original hurdle: the fact couldn't use Conda's command prompt straight from the VS Code or how to activate it once I booted the normal command prompt. Now I know about the .bat startup script at least and could in theory activate it that way each time, but it's kind of awkward, or I could launch a prompt externally and navigate to my working directory, but that's clumsy too. I forgot that this was my first blocker, and on a related note I had similar issues with x64 Native Tools (a Visual Studio based command prompt). I wondered what that was as well, why it looked like an independent terminal but I couldn't launch it in VS Code.
For WSL, yes you are right. Running the conda that you installed for windows would be the same as trying to run any other program that you installed for windows -> it will fail because the binaries are not compatible. You would probably be able to install the linux version there, but as you pointed out, that is not what you want.
For git bash, the solution is more simple than you might think. You can set it up so that you can "talk"to your windows installed conda. Yes, you will need to have the equivalent setup to what you have already discovered for cmd and powershell, but conda already has everything you need to set it up.
Assuming your installation is at C:\Users\foo\miniconda3\, from your git bash, do:
/c/Users/foo/miniconda3/Scripts/activate
conda init bash
this will modify your bash_profile to automatically set up conda for use from git bash
Some clarifications:
I now don't believe this is possible. From a naive user perspective, one sort of assumes they can run any program anywhere, and that makes sense or would have made sense before we had sub-systems and systems within systems, but from a more aware point of view, Anaconda was installed for Windows and inside the C:\ProgramData\Anaconda3 directory are .exe and .bat files, not Linux/WSL compatible binaries and .sh or .bash files. It's like trying to run Windows_OS>Linux subsystem>Windows_file_again, but it doesn't work like that. WSL and Git Bash don't even have the same path structure somehow
WSL, as you have pointed out, is a subsystem and, since wsl 2 runs a real linux kernel. It naturally follows that, as you have said, it is not possible to run windows binaries from it.
Git bash however, is not a subsystem at all. Instead, it is a port of bash for windows. That means when you are in your git bash, you are still within your windows environment. Only the syntax for paths and commands is different (see above commands I have provided), but you are still in the same system.
If you look at the file
C:\Users\foo\miniconda3\Scripts\activate
you will also see that it is a normal .sh script that calls conda.sh at
C:\Users\a-fjochhe\miniconda3\etc\profile.d\conda.sh
So ana/miniconda does indeed come with a set of sh scripts that you can use from a bash terminal in Windows
I want to run octave-gui (Octave 5.1 installed with installer and "C:\Octave\mingw64\bin" is in path variable) scripts run by Windows Task Scheduler. I have to run octave-gui since I want to use the qt toolkit for plotting that octave (without gui) does not support. Therefore I normally use simple bat files like "octave-gui --no-gui c:\path\myfile.m".
But the problem is that I cannot run this bat file by clicking in the Windows Explorer or running from command line. Even the most simple bat file with the content "octave-gui --no-gui" gives me the following error:
But the funny part is that I can make it work somehow:
open command line
run "octave" or "octave-gui" and close/quit it
then I can the bat file from the command line
But this could not be the solution, could it? This only works in the (interactive) command line. How does it work in the Task Scheduler?
So, do you have a solution to run either batch files using octave-gui or octave with qt toolkit.
Here is the workaround with "where" as asked by Gerhard:
The command octave is technically incorrect.
It works only from your Command Prompt window because its extension .bat is listed within the values assigned to an unmodified environment variable %PATHEXT%. It also assumes that there are no other files named octave.com or octave.exe, anywhere within the any of the directories listed under your environment variable %PATH%. Additionally it also assumes that there is not an executable file named octave with any extension listed under %PATHEXT% in the current directory when invoked.
You should, for safety, use octave.bat instead.
octave.bat
Octave.bat will parse any input arguments, set up the required environment, and then run either start octave-gui.exe --gui %* or octave-cli.exe %* if it detected --no-gui as one of the input arguments.
Additionally when running a batch file from another, (in this case start_my_octave_script.bat), you should Call it if you're wanting control to return to it afterwards, which will almost certainly be the case.
call octave.bat <command line options>
If you're satisfied that your %PATHEXT% environment variable is unmodified or at least holds the default values, you can omit the .batextension, but please bear in mind the previous advice.
call octave <command line options>
I made a workaround thanks to the hints made by Compo. It seems to me that a solution must be done in the "octave.bat" and so I did. I made a copy and named it "octave-gui-nogui-withqt.bat" and removed all the gui checking stuff and only run "octave-gui.exe --no-gui" (scroll down):
:; # if running from bash, recall using cmd.exe
:; cmd.exe //c "$0" "$#"; exit $?
#echo off
Rem Find Octave's install directory through cmd.exe variables.
Rem This batch file should reside in Octaves installation bin dir!
Rem
Rem This trick finds the location where the batch file resides.
Rem Note: the result ends with a backslash.
set OCT_HOME=%~dp0\.\..\
Rem Convert to 8.3 format so we don't have to worry about spaces.
for %%I in ("%OCT_HOME%") do set OCT_HOME=%%~sI
Rem Set up PATH. Make sure the octave bin dir comes first.
set PATH=%OCT_HOME%qt5\bin;%OCT_HOME%bin;%PATH%
Rem Set up any environment vars we may need.
set TERM=cygwin
set GNUTERM=wxt
set GS=gs.exe
Rem QT_PLUGIN_PATH must be set to avoid segfault (bug #53419).
IF EXIST "%OCT_HOME%\qt5\bin\" (
set QT_PLUGIN_PATH=%OCT_HOME%\qt5\plugins
) ELSE (
set QT_PLUGIN_PATH=%OCT_HOME%\plugins
)
Rem set home if not already set
if "%HOME%"=="" set HOME=%USERPROFILE%
if "%HOME%"=="" set HOME=%HOMEDRIVE%%HOMEPATH%
Rem set HOME to 8.3 format
for %%I in ("%HOME%") do set HOME=%%~sI
Rem Start Octave (this detaches and immediately returns).
Rem make this call in order to have qt on the cli
octave-gui.exe --no-gui %*
Is this the most elegant one? I guess that upstream Octave should allow a new option like "--no-gui-but-use-qt" or similar. What do you think?
It still confuses me that "octave-cli.exe" and "octave-gui.exe" have more differences besides the visible gui.
I'm trying to do the following:
Open a CMD prompt
Activate a virtual environment
Change the current directory to my project folder
In essence, I need to execute the following commands sequentially:
C:\Envs\djangorocks\Scripts\activate
cd "D:\GitHub\steelrumors"
I've found this link, but creating a shortcut as follows gives me nothing (just a plain CMD prompt in the currently active directory):
cmd \k "C:\Envs\djangorocks\Scripts\activate" & "cd "D:\GitHub\steelrumors""
After quite a while of searching I'm still doing it manually, any help is appreciated.
"creating a shortcut as follows gives me nothing (just a plain CMD prompt in the currently active directory):"
cmd \k "C:\Envs\djangorocks\Scripts\activate" & "cd "D:\GitHub\steelrumors""
Observations:
cmd \k should be cmd /k.
& should be && when using a shortcut.
You dont need all the " characters.
Try the following as the shortcut target:
cmd /k C:\Envs\djangorocks\Scripts\activate && cd D:\GitHub\steelrumors
Consider creating a batch file (e.g. c:\scripts\launchEnv.cmd) that does something like the following:
#echo off
C:\Envs\djangorocks\Scripts\activate
cd /d "D:\GitHub\steelrumors"
Then create a shortcut that invokes cmd /k c:\scripts\launchEnv.cmd .
Some notes:
the #echo off will prevent the commands from showing up in the cmd windows. If you do want to see the commands, then omit that line from your batch file
you'll need the /d param when changing directories to make sure you actually change and navigate there, independent of where the script is currently executing from.
As an extension to the great answer from #DavidPostill I've added an additional step to run a command from the newly created python env.
In my example below, I'm launching a new instance of the awesome data mining program, orange, from an anaconda env called orange. I've also cd'ed to the directory containing my orange data files. Note that I had to use the quotation marks "" to make it work.
C:\Windows\System32\cmd.exe /k "F: && cd \Dropbox\IT\Python\Orange && C:\Users\dreme\Anaconda3\Scripts\activate.bat orange && python -m Orange.canvas"
I just installed gVim, and tried using the usual "vim myfile.java" technique that usually works for linux to open up a file and edit it. But unfortunately, this doesn't seem to work. I've also tried "gvim myfile.java", but that doesn't work either.
Does anyone know how to open up vim (and use it like you do in linux) using Windows Powershell, or some other technique?
When you install gVim:
Please make sure [✓] Create .bat files for command line use is checked.
It'll create several .bat files in C:\Windows\:
C:\>cd %windir%
C:\WINDOWS>dir /b *.bat
evim.bat
gview.bat
gvim.bat
gvimdiff.bat
view.bat
vim.bat
vimdiff.bat
vimtutor.bat
Notice that: C:\WINDOWS is already in the PATH environment variable.
When you type vim in command line, C:\WINDOWS\vim.bat will be launched.
If you leave the checkbox mentioned above unchecked, you need to modify PATH manually.
Just to supplement, I'm on a fairly highly controlled Windows workstation right now, and don't have access to much. Downloading the "executable installer" that I usually use did not create the bat files nor, for some reason, vim.exe, though gvim.exe was installed in the vim74 dir for me and worked fine. So though I also needed to set the PATH, that there was no bat file in C:\WiNDOWS nor any command line executable in my VIm runtime folder to call meant that callingvim from the command line (or Powershell) didn't work.
I'm guessing some portion of the install that's creating the command-line related stuff, apparently including vim.exe, isn't recovering gracefully when you don't have admin permissions.
Either way, the "right" thing to do appears to be to set your PATH to your vim executable folder as usual (note that this might be a little more difficult than usual if you don't have admin privs), then download the "Win32 console executable" from the usual download page that matches the version of gvim that you've already installed, dig vim.exe out of that zip you just downloaded, and place that into the same folder as gvim.exe.
Looking on another box where the executable installer did work "fully", there's some jive in the vim.bat file that wasn't installed for me about "collect the arguments in VIMARGS for Win95" and if .%OS%==.Windows_NT goto ntaction, etc etc, but not having any of that doesn't seem to be a problem on Win7, at least. ;^)
Windows 10 has linux subsystem for windows. So you can install bash in windows and from bash you can use vim.I found it more convenient.
Install gVim on your window and enable ".bat" when you install gvim and click next, done.
You can use vim on window.
Because of restrictions on my workstation, I had to install my instance of vim locally to the following folder: %LocalAppData%\Vim
But just changing an environmental variable like others suggest is insufficient because the batch files aren't in the installation directory (such as vimdiff). So I figured out where these come from, and made my own batch files to add them to an environmental variable. To help you make these batch files, I've provided the list of commands below for you to run in the vim installation directory (if saving the commands to an install.bat file first, replace all % characters with %% to escape it):
echo #echo off > evim.bat
echo gvim.exe -y %* >> evim.bat
echo #echo off > view.bat
echo vim.exe -R %* >> view.bat
echo #echo off > gview.bat
echo gvim.exe -R %* >> gview.bat
echo #echo off > vimdiff.bat
echo vim.exe -d %* >> vimdiff.bat
echo #echo off > gvimdiff.bat
echo vim.exe -d %* >> gvimdiff.bat
Then you have to go to Start > Search 'Edit environment variables for your account' > Find 'Path' > Edit > Add a new subentry for %LocalAppData%\Vim\vim82. Last you may need to close and open the command prompt, or kill explorer.exe and restart it.
I want to use ls in windows command prompt and make it run the dir command.
How can I do that?
You can solve this question with one simple command:
echo #dir %* > %systemroot%\system32\ls.bat
Make sure you run cmd.exe as admin first if you are on vista and up
You could:
create a batch file called ls.bat and have it contain the dir command only
add the directory where the ls.bat file exists to your PATH environment variable
You could then execute ls from a command prompt.
Its an old question but for the record:
http://gnuwin32.sourceforge.net/packages/coreutils.htm
Gives you ls and a whole lot more!
Easiest way I have found is:
Install Git for Windows
Add the bin directory of Git to your Path variable. Mine was located in C:\Program Files\Git\usr\bin.
Start a command prompt and enjoy ls in all its glory.
I have a solution but it's dirty:
Create a file named ls.bat containing only "dir".
Put it in C:\windows\system32 (or any directory in PATH env var).
That (should) works!
Edit: Something more consistent: https://superuser.com/questions/49170/create-an-alias-in-windows-xp
If you have Node.js installed on your system, you can install it from Cash, a library I wrote for Linux commands on Windows:
npm install cash-ls -g
Windows command prompt for Vista/7 will allow NTFS symbolic links, run cmd.exe as administrator then:
mklink ls %System%\dir.exe
Then set up your PATH environment variable to include the location of the link you just created.
If you want more than just the 'ls' command, you should look into cygwin.
EDIT- Just realized dir.exe is not a separate program, so this doesn't really work. But mklink and cygwin are good things to know about.
If you just want to have cmd recognize ls as an alias for dir, you can use the doskey command (from this answer on superuser).
This does not change the original command line parameter handling of the dir command.
+1 on the post above suggesting to install git for windows and add the directory bin to your path variables.
Another way I got touch, ls, and a lot of other UNIX commands working in cmd.exe on my Windows 8 and Windows 7 machines.
Go to the following site to install Cygwin
https://www.cygwin.com/install.html
Install the 32 or 64 bit version for your system. The default settings and packages should include what you need so you don't have to change anything once you get to the packages screen.
After installation, copy the Cygwin folder path to your environment path variables. For example; if you installed cygwin to C:\Cygwin, you will add the following to your environment system path variables:
;C:\Cygwin\bin
On my system I installed the 64bit version and the default folder name and path was C:\cygwin64. So i added the following to my system environment path variables:
;C:\cygwin64\bin
Restart your terminal if it's open. Then type ls and you'll see a directory listing.
See the following if you are not familiar with setting PATH environment variables:
Superuser Link 1
Superuser Link 2
my ls.bat was below
#dir %*
that can transfer cli args
ls /b
ls /w
put it in %windir% or any directory in your %PATH% variable.
Just make sure you save the file with ANSI encoding :)
you could also use cygwin and just use the ls command directly along with all the other unix command line tools you might be used to.
I recommend the following recipe.
Use DOSKEY and $* to create your ls command.
Make the command persistent by recording it in a .bat/.cmd file and add the path of the file to registry.
For example, your command may look like
DOSKEY ls=dir
DOSKEY sublime="C:\Program Files\Sublime Text 2\sublime_text" $*
$* is useful for commands that take on arguments. For example, here I like to be able to do sublime my_code.c.
The registry for cmd is at HKEY_CURRENT_USER -> Software -> Microsoft -> Command Processor. Create a string valued entry called AutoRun with the full path of the file (not the containing folder) such as %USERPROFILE%\custom_command.cmd. Then each time cmd is run, your command will be loaded!
You can add more useful stuffs to the batch file too. See here for an example template.
Another solution that worked for me is to use UnxUtils, which adds multiple utilities from executable files (including ls, sed, and grep).
To use: download source code. Unzip. Add the UnxUtils\usr\local\wbin path to the Windows PATH variable. Start a new CMD instance.
The most easiest way is
install git
add C:\Program Files\Git\usr\bin to your path variable
now you can use ls
Someone who uses Linux Subsystem for Windows could call ls from the Linux bash. The following Command creates the ls Command in System32:
echo #bash -c "ls %*" > %systemroot%\system32\ls.bat
(The Linux Subsystem feature must be enabled/installed first)
You could follow this guide:
https://gist.github.com/vladikoff/38307908088d58af206b
TL;DR: pass /K path/to/custom/init_cmd.bat to your "shell startup" command.
I'm using ConsoleZ as my shell wrapper, so in my case I can find the setup option in "tabs", then I set the shell path to "C:\Windows\System32\cmd.exe "/K C:\cmd_init.bat""
like this.
Where C:\cmd_init.bat is the batch script containing my macros, here's what I would go for:
#echo off
doskey ls=dir /b
rem other macro stuff..
Sorry for formatting and other mistakes, this is my first time answering here.
I hope it helps!
Create an alias in .bat or .cmd file using doskey key:
#echo off
title "ls command cmd bar"
doskey ls=echo off $T dir $* $T echo on
Enjoy =)
Surely ls would not work as a unix command for the batches. If you check %1 for -l or -a etc. and all combinations of them, it would work...
Here is my C# source code and binary.
Just add ls.exe somewhere and add the path to the path environment variable.