DosTips.com

I have various batch scripts in sundry places.

Via Windows GUI I can double click to launch, and when it has completed it closes.

I do NOT want it to close, I want it to stay open and available to rerun the command

I now have a single line script called CMDexe.BAT which simply invokes CMD.EXE
and that launches CMD.EXE with the current directory and drive set to where this script is held.
Then I can simply type the name of another batch file in the same folder and that is executed.
I can then use DOS shortcuts to repeat the command - I do not have to retype it.

I would like to avoid the need for a separate CMDexe.BAT to be held in each folder from which I may wish to run other scripts.

I would really like some sort of CMDexe.bat which can be placed on the desktop, and when any script is drag-dropped from any drive and folder it should launch CMD.EXE so it aims at where the drag-drop came from.
It would be a very welcome bonus if it could in addition launch the script.
This instance of CMD.EXE must stay open until the command "EXIT", and remain available to rerun the drag-drop script and or perform any other commands that DOS can do.

Regards
Alan

Alan

You could try something like that


You could use
%!%
[Enter]
to rerun the batchfile.

Hope this is what you're looking for.

Regards
aGerman

Thank you so much.

I like the extra bonus of "/t:1F",
a pleasant change from the normal drab DOS colours of dingy White on Black

Regards
Alan

You're welcome.

alan_b wrote:I like the extra bonus of "/t:1F",

I did it for easy noting that it isn't the ordinary command prompt.

Regards
aGerman

Please explain any benefit of
start "%~nx0" cmd /t:1F /k %!%
versus
start "%~nx0" cmd /t:1F /k "%~1"
I see no difference in results, other than whether a variable ! is set

I am especially intrigued by the use of a variable named !
Most variables use one of more letters of the alphabet.
The variable ! is outside the normal range, and I see two special quirks :-
You cannot set the value whilst delayedexpansion is enabled ;
You cannot use delayedexpansion to access its value by surrounding with more !

1. DOS responds to

with "Environment variable \#\T\U\Z.bat" not defined"

2. DOS responds to

with
("D:\#\T\U\Z.bat")
()

Regards
Alan

alan_b wrote:Please explain any benefit of
start "%~nx0" cmd /t:1F /k %!%
versus
start "%~nx0" cmd /t:1F /k "%~1"
I see no difference in results, other than whether a variable ! is set

There is no difference. %!% is shorter, thats all.

alan_b wrote:I am especially intrigued by the use of a variable named !
Most variables use one of more letters of the alphabet.
The variable ! is outside the normal range

This is the reason why I used "!". Normally you would not use it in a batch file and I thought it's easy to write if you want to rerun the batch file.

alan_b wrote:..., and I see two special quirks :-
You cannot set the value whilst delayedexpansion is enabled ;
You cannot use delayedexpansion to access its value by surrounding with more !

You are absolutely right. ! was only an example. Feel free to use any other character.

Regards
aGerman

Thanks for reply.

You taught this old dog a new trick when I asked why your scripts start with "@echo off &setlocal".
I felt I had to ask about ! in case that might lead more "special" knowledge.

Regards
Alan

Alan

When I read your post I wondered why you changed my code starting with "setlocal enabledelayedexpansion". Don't do that.
The "!" as variable name doesn't affect the drag'n'dropped batch file, because you use it only into the parent cmd process. And if there is no "setlocal enabledelayedexpansion" it will work (regardless how you started the dropped file).

Regards
aGerman

Sorry, I actually continued with all of your code, including the first two lines
@echo off &setlocal
if "%~1"=="" goto :eof

It was after that when I threw in an experiment to see what happened when delayed expansion was enabled either before or after trying to set the value of !

It was only my tests for expected quirks, and I removed the extra setlocal enabledelayedexpansion after completing the test.

My final code is now D:\#\T\Drag-n-Drop.bat and contains


The only functional difference is that when my 26th test script named Z.bat has completed,
My version of your code "start "%~1" cmd ..." has a DOS Window title "D:\#\T\U\Z.bat",
Whilst your original code "start "%~0" cmd ..." has a DOS Window title "D:\#\T\Drag-n-Drop.bat"

There was one minor variability in operation of Drag-n-Drop.bat.
When I use Windows Explorer to select D:\#\T\U\Z.bat and drop onto the desktop icon for Drag-n-Drop.bat,
CMD.EXE is launched with White text on Blue, and runs the script D:\#\T\U\Z.bat
and to rerun I have to type "Z" followed by enter - the UP arrow key does not find "Z" in its history.
But after Z has rerun then the UP arrow key does get the last command from history.

The variability is that I am sure that on one occasion the UP key did retrieve "Z" from history immediately after the very first run caused by a drag/drop

I have tried both your version and my version of Drag-n-Drop, and cannot reproduce what I saw.
I have been altering Z.BAT whilst running various tests.
Is it possible that code in Z.BAT might affect what is held in history after the first drag/drop launch ?

So long as I only have to type the "missing history" only once I am more than happy,
it is just that for 40 years as an engineer I have always been "all over" any anomaly with a concern to ensure that no unexpected disaster should come "all over" me.

Can there be race hazards and peculiarities if Z.BAT has been altered but the changes not yet flushed from cache to the drive before the drag/drop is done ?

( Some time ago a script made extensive use of REG.EXE and piped both the console stream and the error stream into a common Response.Log. Some actions gave a simultaneous response on both streams, and I found Response.Log captured 99% of all responses.
Then I changed the location of Response.Log to the furthest partition on the drive, and then it caught all of 9 responses from both streams, and missed both stream responses from the next command, and repeated - very regular loss of 10% of all data as two different output streams were simultaneously colliding - it seemed that DOS appended the first stream message it saw and if the ever growing Response.Log had not been completely re-written and the file "closed" ready for a re-read and append by the second stream then both response got lost.)

In conclusion, I am happy with Drag-n-Drop.bat, it perfectly meets my needs, and I have moved on with the scripts that I am now drag/dropping. I will stop thinking about the peculiarity I am sure I saw - I could be wrong.
Please do not put any effort into this but if you spot some feature in the code that might result in anomalous behaviour please let me know.

Regards
Alan

Sorry but your code is broken by XP
The cure is to never execute the DOS command with a path
%~1
always use the name only
%~nx1
This is safe to do because you previously aimed at the path with cd /d "%~dp1"
I was using a slightly smaller variant of your code, but my variant is broken also

DOS is able to execute type D:\Downloads\CleanUp(2)\hello.bat
but quite unable to execute D:\Downloads\CleanUp(2)\hello.bat
It thinks the command is only D:\Downloads\CleanUp
and I guess it equates "(" with a white space delimitter,
and if there was a cleanup.bat it would probable be given "2)\hello.bat" as an argument.

This is the second time this week that () brackets have caused me grief.

Below is what DOS shows me.
The first group of two line result from dropping hello.bat onto the desktop link to your script
The second group shows that DOS cannot execute an executable when told the path
The third group shows that DOS is able to TYPE a file even when told the path
The forth group shows that DOS CAN execute an executable when NOT told the path.

'D:\Downloads\CleanUp' is not recognized as an internal or external command,
operable program or batch file.

D:\Downloads\CleanUp(2)>D:\Downloads\CleanUp(2)\hello.bat
'D:\Downloads\CleanUp' is not recognized as an internal or external command,
operable program or batch file.

D:\Downloads\CleanUp(2)>type D:\Downloads\CleanUp(2)\hello.bat
@echo off
echo/ Hello World
echo/ CMD.EXE is broken
echo/ Come back Command.com - all is forgiven
echo/ The Sky is Falling - Chicken Little was right.

D:\Downloads\CleanUp(2)>hello.bat
Hello World
CMD.EXE is broken
Come back Command.com - all is forgiven
The Sky is Falling - Chicken Little was right.

D:\Downloads\CleanUp(2)>

Please note that I did not choose the path - XP chose it.
I download an updated CleanUp.zip, but Windows already had that so renamed it CleanUp(2).zip
When I unzipped the contents were, by default, placed in a new folder with the same name,
hence the full path containing the extracted code was in D:\Downloads\CleanUp(2)
And then disaster struck.

This problem IS NOT restricted to this Drag-n-Drop script,
it even applies to manual keyboard entries.
I only tested about one dozen "strange" characters and found "(" and "=" have this problem, but ")" does no harm.
It is possible that many more "strange" characters will also cause CMD.EXE to "blow a gasket".
Do you have list of all the "strange" characters that would cause grief ?

I suggest it is worth putting a permanent "sticky" or Snippets Index warning about this characteristic of CMD.EXE

Regards
Alan

Alan

This is realy strange.
The Windows help for CMD said

But if you use "%~1" you have always quotes around the path.
No idea why this crashes the batch execution.

Ragards
aGerman

You are right, as always ! !

I noticed that DOS did not like ( as part of the file path

I had assumed the quotes were essential for dealing with spaces in paths and file names,
and had not realised they were also needed for the special characters you have just listed.
Since there were no spaces in the paths and file names I did not bother with quotes when I entered the command on the command line.

I have now tried again with the quotes on the command line and DOS does what I tell it.

I concur - something strange about batch execution

You taught me to try try and try again with %% etc, and I find that works with " as well ! !
i.e. this works
start "%~1" cmd /t:1F /k ""%~1""

This script I developed earlier this afternoon is my favourite

Nothing is actually started unless "%~1" is non-null and cd /d "%~dp1" is successful.
This has the benefit that if CD hits an error the script will not attempt to run any file with the correct name that might exist on the existing path.

Regards
Alan

alan_b wrote:This script I developed earlier this afternoon is my favourite

Code: Select all

@echo off &setlocal
if "%~1" NEQ "" cd /d "%~dp1" && start "%~1" cmd /t:1F /k "%~nx1"

Nothing is actually started unless "%~1" is non-null and cd /d "%~dp1" is successful.
This has the benefit that if CD hits an error the script will not attempt to run any file with the correct name that might exist on the existing path.

I thought about it.
Of course, you will find out if the path exists, but you don't know if the file exists.
What about:


Regards
aGerman

THANKS - EVEN BETTER

Regards
Alan

And a last suggestion (to make sure it's a batch file):



Regards
aGerman