Batch files from any file name?

[David Trimboli]

This may seem an odd question.

Is there any way to run a batch script from anything other than a .bat
or .cmd file?

In Unix, I can create a batch file of any name, then run, for instance,
sh <filename>
to execute the batch.

In cmd.exe, the same doesn't work.

I'm not trying to do anything in particular; I was just wondering if
there is a way to do this that I hadn't thought of.

The reason this occurs to me is that I like to mimic Unix's habit of
using .* files for configuration, so my cmd autorun file is ".cmd", my
mail signature is ".signature", my macro file is ".doskey", and so on.
However, since I prefer not to view file extensions for known file
types, ".cmd" is displayed in Windows Explorer as a file without a name,
but which runs as a batch file. Thus, I wondered if there was a way to
create a ".autorun" file or some such which could be run directly as a
batch file.

(Sure, I could create a macro or something that secretly renames the
file with a .cmd, runs the batch, then renames the file back again, but
that's cheating!)

 

[Mark Blain]

Is there any way to run a batch script from anything other than a .bat
or .cmd file?

In Unix, I can create a batch file of any name, then run, for instance,
sh <filename>
to execute the batch.

In cmd.exe, the same doesn't work.

Not a true script, no. Cmd.exe distinguishes scripts solely by file
extension. There is definitely no feature to recognize scripts by
"executable" permissions in the file system or by the famous unix
hashbang (#!/bin/sh)

You can execute individual commands in "yourfile" one-by-one using
redirection or "for /f", but that trick is of limited usefulness.

(Create a file containing a couple of harmless dir commands.)

for /f %i in (yourfile) do %i
or
cmd <yourfile
or
type yourfile | cmd

To run scripts as you describe try a Windows port of a unix shell,
such as those available in Cygwin, Mingw/MSYS or MS Windows
Services For Unix.
http://www.cygwin.com
http://www.mingw.org/
http://en.wikipedia.org/wiki/Microsoft_Windows_Services_for_UNIX

 

[David Trimboli]

Not a true script, no. Cmd.exe distinguishes scripts solely by file
extension. There is definitely no feature to recognize scripts by
"executable" permissions in the file system or by the famous unix
hashbang (#!/bin/sh)

Thanks, Mark. That's what I thought.

You can execute individual commands in "yourfile" one-by-one using
redirection or "for /f", but that trick is of limited usefulness.

Neat idea! I hadn't thought of that. No, it's not what I meant, but it's
creative.

 

[Herb Martin]

Thanks, Mark. That's what I thought.


Neat idea! I hadn't thought of that. No, it's not what I meant, but it's
creative.

One issue with Cygwin is that for all your current batch files with
extensions, you must type the ?##%$* extension or they don't
work from the CygWin session. (Mybat.cmd is necessary there
if the file has an extension.)

 

[Al Dunbar [MS-MVP]]

Thanks, Mark. That's what I thought.


Neat idea! I hadn't thought of that. No, it's not what I meant, but it's
creative.

Yes, way cool. But the for/f trick is severely limited, considering:

- the problems that will result from the external script containing any
special characters that need special treatment;
- references to batch parameters;
- compound statements occupying more than one line;

Way simpler to use the .cmd extension in the first place.

/Al

 

[David Trimboli]

Way simpler to use the .cmd extension in the first place.

Quite true. I just find it odd that batch files, which are simply text
files containing command lines, absolutely must have .cmd or .bat to work.

Perhaps this is a security feature, to prevent running batch commands
from arbitrary (and thus undetectable) text files?

 

[Herb Martin]

Quite true. I just find it odd that batch files, which are simply text
files containing command lines, absolutely must have .cmd or .bat to work.

Perhaps this is a security feature, to prevent running batch commands from
arbitrary (and thus undetectable) text files?

Could be but it probably just an historical artifact of the original
command processor code -- and no one has ever seen a reason
for changing it, or when they thought of changing it then decided
security was better this way.

It wan't until fairly recently that the list of file extensions that are
"executable" could be extended, and I have personally tried to
extend it by the <nul> extension with no success.

 

[Al Dunbar [MS-MVP]]

work.

Batch files do not "work" on their own, but are processed by the O/S. And I
have mostly always found it a waste of time to argue with the O/S on these
things.

Do executable files work with extensions other than the few obvious ones?
vbscript files?

Whether or not by design, that certainly simplifies things for software that
is designed to quarantine files of certain types...

Could be but it probably just an historical artifact of the original
command processor code -- and no one has ever seen a reason
for changing it, or when they thought of changing it then decided
security was better this way.

Could be. I remember using a minicomputer O/S long ago that had a batch file
equivalent. But it also had a built-in command that allowed one to run a
batch file regardless of the type of the file. Could be done here with CALL,
except that that works for .exe's as well...

/Al

 

[Michael Bednarek]

Al Dunbar [MS-MVP] wrote:
Way simpler to use the .cmd extension in the first place.

Quite true. I just find it odd that batch files, which are simply text
files containing command lines, absolutely must have .cmd or .bat to work.

Batch files do not "work" on their own, but are processed by the O/S. And I
have mostly always found it a waste of time to argue with the O/S on these
things.

Not strictly true; batch files are processed by a batch file processor,
which is usually also a command line processor (CLI). A popular sample
CLI is CMD.EXE; there are others.

Do executable files work with extensions other than the few obvious ones?
vbscript files?

[snip]

Yes: rename NOTEPAD.EXE to anything.any and:
start anything.any
will run it.

Also:
cscript //E:vbscript fu.bar
will work as expected. See:
<http://www.microsoft.com/technet/scriptcenter/guide/sas_wsh_divn.mspx?mfr=true>.

OTOH, there seems to be indeed no method to make CMD.EXE or COMMAND.COM
(or 4NT for that matter) to process a file with a non-standard
extension.

 

[David Trimboli]

Do executable files work with extensions other than the few obvious ones?
vbscript files?

[snip]

Yes: rename NOTEPAD.EXE to anything.any and:
start anything.any
will run it.

Also:
cscript //E:vbscript fu.bar
will work as expected. See:
<http://www.microsoft.com/technet/scriptcenter/guide/sas_wsh_divn.mspx?mfr=true>.

OTOH, there seems to be indeed no method to make CMD.EXE or COMMAND.COM
(or 4NT for that matter) to process a file with a non-standard
extension.

Thanks for the notes, Michael. The bit about renaming notepad.exe was
particularly interesting.

 

[Jason Gurtz]

This may seem an odd question.

Given the fact that the concept of a filename as metadata is fraught
with peril I would say that this is not odd but, in fact, a rather valid
complaint IMO.

In Unix, I can create a batch file of any name, then run, for instance,
sh <filename>
to execute the batch.

In cmd.exe, the same doesn't work.

It struck me that you could probably accomplish this in powershell via
acrobatics with the -command option.

powershell.exe -command - < .myHiddenScriptFile

I tested and created a text file called helloWorld (with no extension)
that contained the single line:

echo "Hello World!"

Then, at a cmd.exe prompt:

C:\tmp>powershell -command - < helloWorld
Hello World!

C:\tmp>

Looks like a winner! It looks like if you create a cmdlet then you can
even do powershell <cmdLetName> but it appears to have the same bug as
cmd in requiring a specific extension (.ps1) *bleh*

There are rumors of the windows terminal emulator being rewritten (maybe
hopefully in Longhorn server?) hopefully they would add shabang style
functionality to that along with the other long needed fixes.

~Jason

--

 

[David Trimboli]

It struck me that you could probably accomplish this in powershell via
acrobatics with the -command option.

Yes, most shells allow it; cmd.exe does not. If it's because of
security, then PowerShell limits it by preventing scripts from being run
by double-clicking or typing the file name without a path, and even
disables scripts by default.

I really have to improve my PowerShell-Fu.