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.
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.
There are a number of examples on the web of how to run a file from the Notepad Plus Plus (NPP). But they all fail to account for the fact that the current working directory is the location of the NPP's executable, and not the location of the file.
Usually they go something like this:
cmd /K "$(FULL_CURRENT_PATH)"
Consider the following Python script:
with open('somefile.txt', 'a') as file:
file.write('Hello there.\n')
This file will be created in the NPP folder, which is not at all what most people would expect. Most people would want it in the same location as the Python file.
You could also do something like this, and it works as expected, but this limits you to Python files only:
<Command name="Run This Python File" Ctrl="no" Alt="no" Shift="yes" Key="116">cmd /K python "$(FULL_CURRENT_PATH)"</Command>
I would not want to add extra code to the Python script to change the current working directory, as normally this would not be needed.
I have been trying to solve this and came up with the following. This line goes in "shortcuts.xml" in the NPP folder.
<Command name="Run This File" Ctrl="yes" Alt="no" Shift="no" Key="116">cmd /K "cd "$(CURRENT_DIRECTORY)" && "$(FULL_CURRENT_PATH)""</Command>
So you shut down the NPP, edit the "shortcuts.xml" by adding this line, using another editor, then launch the NPP.
To run the file, use Ctrl+F5 key combination.
This works in Windows 10, but fails in Windows XP.
How can I tweak it to work in Windows XP?
Try this:
cmd /k cd /d $(CURRENT_DIRECTORY) && python $(FULL_CURRENT_PATH)
My guess would be that the problem is the improperly nested quotes in the command; I'm not sure exactly why it would work on later Windows' while failing on XP.
The command
cmd /K "cd "$(CURRENT_DIRECTORY)" && "$(FULL_CURRENT_PATH)""
represents
cmd /K "cd "$(CURRENT_DIRECTORY)" && "$(FULL_CURRENT_PATH)""
Even from the syntax highlighting you can see that the quotes are not quoting what you expect.
To get the desired effect, you can use this command:
cmd /K cd "$(CURRENT_DIRECTORY)" ^&^& "$(FULL_CURRENT_PATH)"
:: XML-ified:
cmd /K cd "$(CURRENT_DIRECTORY)" ^&^& "$(FULL_CURRENT_PATH)"
I run several Windows .bat files from Notepad++. To achieve this one of the entries in the <UserDefinedCommands> section of the file C:\Users\AdrianHHH\AppData\Roaming\Notepad++\shortcuts.xml is:
<Command name="CD and run file" Ctrl="no" Alt="no" Shift="no" Key="0">cmd /C "cd /d $(CURRENT_DIRECTORY) && $(FULL_CURRENT_PATH)"</Command>
With the .bat as the current file I then use menu => Run => CD and run file.
The command line shown in the question appears to have too many " symbols. The current directory includes the drive specifier and so the CD needs the \D option.
The command I use starts cmd \C ... (rather than the \K in the question) so the command window closes automatically. My .bat files normally finish with choice /t 60 /C Y /d Y /n so I can see the command's output.
Notepad++ > F5 (Run) > then type following command
cmd /K cd "$(CURRENT_DIRECTORY)" && python "$(FULL_CURRENT_PATH)"
assuming you have setup the path, or you may use C:\Python27\python.exe or the path of your python binary, and you will run the python at the folder where the python resides in. You can also save this command to shortcut by clicking button Save....
Afterwards, you also can modify the command in toolbar > Run > Modify shortcut/delete command.
I've just downloaded ActivePerl for Windows 10 on my 64 bit laptop, but when I go to the command prompt, perl -v fails unless the directory is C:\Perl64\bin in which case it tells me that I have Perl 5.20.2 Copyright Larry Ullman etc, but if I try and open perl files anywhere, nothing happens, if I run perl.exe it just shows me a command window with a flashing bar and nothing happens, and when I try and run .pl programs in Eclipse it tells me predictably that because perl-v failed it won't run.
What can I do to get .pl files running?
You must create a file association between the .pl file extension and the Perl runtime.
At a command prompt type the following.
assoc .pl=PerlScript
ftype PerlScript=c:\perl\bin\perl.exe %1 %*
Choose perl.exe or wperl.exe, depending on your need to get a visible command window.
To get perl to be recognized, you must add C:\Perl64\bin to the PATH environment variable. Go to Control Panel > System > Advanced System Settings > Environment Variables. Edit the line containing PATH in the top box marked User variables for , and add ;C:\Perl64\bin (note the semicolon) to the end. Be sure not to corrupt anything that's already there.
installing perl in windows 7
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.