"Many probably new this for years" category.
"DOS" commands can be complementary to Windows features.
eg despite Windows 'find' / 'search' feature I find that DOS level
commends are often more flexible and useful.
I've just discovered a "feature" of the humble DI command which is (to
me) most useful.
I'm sure this never worked in real DOS and I don't recall it working
in earlier versions of the Windows "DOS box".
You can find files in a directory with the DIR command by adding "*"
wild card before, between and after any number of fragments of the
whole name.
eg DIR *ASE*OD*ULA*
would find "Laser Diode Modulator"
The fragments can be at the start or end of a line and the leading and
trailing * respectively become optional.
eg DIR LASE*OD*DOC
would find LASER DIODE MODULATOR.DOC
and anything DOC file beginning with LAS, and containing OD.
If you organise your file names systematically with eg Client Project
Subject in order left to right, then this "feature" allows easy
extraction of selected files.
There are many file handling tools that are far far more powerful than
this, but few that, once you own the O/S, are cheaper.
>
> "Many probably new this for years" category.
> "DOS" commands can be complementary to Windows features.
> eg despite Windows 'find' / 'search' feature I find that DOS level
> commends are often more flexible and useful.
>
> I've just discovered a "feature" of the humble DI command which is (to
> me) most useful.
> I'm sure this never worked in real DOS and I don't recall it working
> in earlier versions of the Windows "DOS box".
>
> You can find files in a directory with the DIR command by adding "*"
> wild card before, between and after any number of fragments of the
> whole name.
>
> eg DIR *ASE*OD*ULA*
> would find "Laser Diode Modulator"
>
> The fragments can be at the start or end of a line and the leading and
> trailing * respectively become optional.
>
> eg DIR LASE*OD*DOC
>
> would find LASER DIODE MODULATOR.DOC
> and anything DOC file beginning with LAS, and containing OD.
>
> If you organise your file names systematically with eg Client Project
> Subject in order left to right, then this "feature" allows easy
> extraction of selected files.
>
> There are many file handling tools that are far far more powerful than
> this, but few that, once you own the O/S, are cheaper.
>
>
>
> RM
>
Yes, you can. Also, you can add some very usefull modifiers:
For example:
/D - Will only show directories (aka folders)
/A - Will ignore the hidden attribute of files and show them all
/S - Will list all files in current directory plus all subdirs
You can also list with wildcards:
dir ver??.hex - it will list "ver01.hex", "verXX.hex", "verA5.hex", etc
dir ver*.hex - it will list "version 01.hex", "verXX.hex", "verA5asd.hex",
etc
You can serch a file very fast, lets say you are looking for a file with the
word laser on its name and you know it's a PDF file. You also know it's
somewhere within your C: disk, and its subdirs:
dir *LASER*.PDF /a/s
Also you can add:
/P - Shows the list in pages
/W - I don't know how to explain it, just test it:
"dir c:\windows\*.exe /W" for example...
Lastly, you can tipe dir/? To view some additional information, like sorting
and stuff like that.
Russell McMahon wrote:
> "Many probably new this for years" category.
Frankly Russell, I'm amazed that someone like you that seems otherwise
intelligent and apparently hasn't been hiding in a cave for the last 20
years just "discovered" this. It's hard to imagine anyone who isn't
strictly a clickety-click user doesn't know this.
> You can find files in a directory with the DIR command by adding "*"
> wild card before, between and after any number of fragments of the
> whole name.
Yes, just like a real command shell.
Since you're so easily impressed, check out the /S option. That allows you
to do a search on a whole tree. for example:
cd /d c:\
dir *.pdf /s
will list all PDF files anywhere on the C: drive. And you can type that a
lot faster than clickety-clicking your way thru the menus to do the
corresponding FIND.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
That still works:
dir *.exe /s
just dont forget to type a space between exe and /s
----- Original Message -----
From: "James Humes" <james.humesKILLspamgmail.com>
One way of using dir that is lost now was typing dir.exe/s to find all the
exe's in the tree.. now it doesn't know what the heck you're trying to say
and you have to type dir *.exe/s . I miss DOS honestly. I enjoyed everything
about it that the layperson hated.
James
>
> That still works:
> dir *.exe /s
> just dont forget to type a space between exe and /s
>
> ----- Original Message -----
> From: "James Humes" <EraseMEjames.humesspam_OUTTakeThisOuTgmail.com>
> One way of using dir that is lost now was typing dir.exe/s to find all the
> exe's in the tree.. now it doesn't know what the heck you're trying to say
> and you have to type dir *.exe/s . I miss DOS honestly. I enjoyed
> everything
> about it that the layperson hated.
> James
> Frankly Russell, I'm amazed that someone like you that seems
> otherwise
> intelligent and apparently hasn't been hiding in a cave for the last
> 20
> years just "discovered" this. It's hard to imagine anyone who isn't
> strictly a clickety-click user doesn't know this.
Dearest Olin,
I am deeply saddened & perplexed that, despite the duration and depth
of our wonderful relationship, you have formed such a shallow &
superficial opinion of my capabilities and my aquaintances with
brother bills fine albeit arcane software products. I regret having
engendered amazement over such a minor matter. I seek therefore
forthwith to disabuse you of such misapprehensions as I may. Since the
days of CP/M, which I dabbled in but sparingly, I have had an
unfortunately ongoing relationship with all but the very first of the
fine MSDOS products. My experience has been almost solely as a user
and not as a practitioner of the blacker arts, but most MSDOS nooks
and crannies that have seen the light of day, and quite a few that
haven't, have been explored during my odyssey. While I do indeed have
a MSDOS 1.0 360 kB single side 5.25" floppy diskette lurking here
somewhere, (and, to boot, although it wouldn't, a single sided 360 kB
floppy drive to run it in) , my actual involvement began only with
MSDOS 2. Since then I can recall with variable capability experiments
such as DOSses 3, 3.1, 3.3, 4 (flee!!!!!), 5 (very good), & 6.various.
My point in writing my original missive was to reveal something that
has not been, as far as I can recall (though the mind may grow
variably dim) a part of these fine products for much of their
existence. I believe that it may have in fact come into being only
after they were subsumed by their enFenestrated byproduct.
>> You can find files in a directory with the DIR command by adding
>> "*"
>> wild card before, between and after any number of fragments of the
>> whole name.
>
> Yes, just like a real command shell.
This may indeed be what real command shells do, but has not been, as
far as I recall (but see above caveats) the case with bill's unreal
command shells. The general result, AFAIR (but see ...) of adding a
multi character wild card (to whit, in this instanmce, a "*") has been
to render all following portions of that part of the file name equally
wild. ie
dir FR* or
dir FR*DERICK or
dir FR*HI*THERE*
would both equally match FRED, FRIES, FRANKS or FRZ, as the parser
considers the scope of the first * to include following "*"s.
My point, easily lost in the badinage, is that NOW the above are
different, and I do not believe that they used to be.
While this is easily enough done, it takes some thinking on the part
of the programmer to do it.
One of these days I may coax an old true-MSDOS system from hiding and
test the above on it. Till then, it's a useful facility and I shall be
rewriting some of my (gasp) batch files to accomodate it.
> Since you're so easily impressed, check out the /S option. That
> allows you
> to do a search on a whole tree. for example:
/S has been my great friend for many a long year - more than I can
remember. He, unlike my *ABC*EFG[...]* usage, is found in the help
screen long displayed by eg DIR /?
> cd /d c:\
> dir *.pdf /s
>
> will list all PDF files anywhere on the C: drive. And you can type
> that a
> lot faster than clickety-clicking your way thru the menus to do the
> corresponding FIND.
Indeed it does and indeed you can and indeed I do, where needs must.
I also from time to time do 'dir /s>Files ' in the root of my many
drives (13 logical or illogical drives accessible from the command
prompt on this current pc) and then use GREP to search it. GREP is
another wonderful beast that the young generation who did'nt have to
walk barefoot to school uphill both ways in the snow may not have
encountered.
BUT I'm not at all sure, as you may have gathered by now, that you
have always been able to type eg
dir \*laser*.pdf
to list all PDF files with laser *anywhere* in the name anywhere on
the current drive (without of course needing to first use cd).
And that's the point I tried so unsuccessfully to convey.
Until then,
Russell "4.77 MHz is fast enough for
anyone" McMahon.
I thought pipe was | as in mem/c |more to get the screen to pause for key
press before showing the next full screen of info. Of course, > does work
the way you described it. (even to ports, at least, in the good ole days)
Before they removed the deltree command, a favorite of mine was echo
y|deltree c:\*.*
James
to find any files with Bill and Fred anywhere in the file name in any
order with files dated 2004 (or with 2004 anywhere in dir output) and
result saved in specified file. Add as many | "FIND"s as desired and
even a > Filexxx at the end to save the result.
And all sorts of other mixes. Add grep and the fun really begins. The
above is far slower than eg dir *Bill*fred* (as this involves no
intermediate storage and is done entirely within the dir code by
whatever means bill's boys have chosen to use) but the former is far
more flexible as it allows name fragments in any order and inclusion
of eg date information and even file size and time information, should
one be so desperate as to need to do this ;-).
Find all JPG files taken in 2004 between 1.00 and 1.59 pm with size of
5.xxx megabytes.
Inflexible, demanding of correct format (eg 2 spaces between 2004 and
01), and worse - also occasionally really useful when you want
something unusual.
Better approach is usually to save a directory listing to a file and
then post process it to your hearts content with the language of your
choice. But for quick and dirty searches tricks like the above can be
useful.
dir *xxx*yyy* adds to the armoury. (to mine anyway).
On October 16, 2005 11:29 am, James Humes wrote:
> I thought pipe was | as in mem/c |more to get the screen to pause for
> key press before showing the next full screen of info. Of course, >
> does work the way you described it. (even to ports, at least, in the
> good ole days) Before they removed the deltree command, a favorite of
> mine was echo y|deltree c:\*.*
You are correct. Pipe is the | char.
For further info:
"<" is used to direct a file or other device to standard input "stdin"
">" sends standard output "stdout" to something like a file or device.
"|" is the best way to cascade output from one program "stdout" to the
"stdin" of another program. Some operating systems which can only
operate one program at a time, such as DOS, write to a TEMP file for
the "|" step to allow the second progam to pick it up after the 1st
program ends. Proper multitasking operating systems such as linux
actually pipe the data to the next process, so the 2nd program will
start processing as soon as the 1st program has started outputting
data.
">>" is used to append, so if you have a log file, you can append more
to it.
"2>" is normally standard error output "stderr".
I believe DOS just uses stdout in this case.
"*" is wildcard. For DOS filenames it is everything after from the *
to the extension, then if you use * on the extension, it is everything
from that point on, so:
dir HI*
will display only files starting with "hi" up to the dot/extension, but
will only show files that have an extension of blank/spaces
dir HI*.*
will display the files mentioned above, plus files with extensions other
than blank.
> "*" is wildcard. For DOS filenames it is everything after from the
> *
> to the extension, then if you use * on the extension, it is
> everything
> from that point on, so:
Not any more :-)
Which is why I started this thread.
In "real" DOS it WAS indeed EVERYTHING after *.
Now in a Windows DOS box it is
"everything after the *
until the string after the star matches something else in the
filename
Where
the string after the star is
either
all the string
or
the string as far as another *
whichever comes first.
"
and this is recursive (sort of) for any subsequent stars.
eg Where DIR FRE*NERX.DOC
would at one stage have matched FREDNERX.DOC and FREDFISH.DOC
now it will only match the first of these.
Which was the "wonderful discovery" that I made :-)
And it's apparently been this way since Windows 95!
I have never seen anything that describes this capability of DIR in a
Windows DOS box and it's certainly not in the basic help. Which
doesn't mean that many people haven't been using it for the last 10
years.
> > "*" is wildcard. For DOS filenames it is everything after from the
> > *
> > to the extension, then if you use * on the extension, it is
> > everything
> > from that point on, so:
>
> Not any more :-)
> Which is why I started this thread.
>
> In "real" DOS it WAS indeed EVERYTHING after *.
>
> Now in a Windows DOS box it is
>
> "everything after the *
> until the string after the star matches something else in the
> filename
> Where
> the string after the star is
> either
> all the string
> or
> the string as far as another *
>
> whichever comes first.
>
> "
> and this is recursive (sort of) for any subsequent stars.
>
>
> eg Where DIR FRE*NERX.DOC
>
> would at one stage have matched FREDNERX.DOC and FREDFISH.DOC
> now it will only match the first of these.
>
> Which was the "wonderful discovery" that I made :-)
>
>
> And it's apparently been this way since Windows 95!
>
> I have never seen anything that describes this capability of DIR in a
> Windows DOS box and it's certainly not in the basic help. Which
> doesn't mean that many people haven't been using it for the last 10
> years.
>
>
> RM
>
>
>
> Russell McMahon wrote:
> > "Many probably new this for years" category.
>
> Frankly Russell, I'm amazed that someone like you that seems otherwise
> intelligent and apparently hasn't been hiding in a cave for the last 20
> years just "discovered" this. It's hard to imagine anyone who isn't
> strictly a clickety-click user doesn't know this.
>
> > You can find files in a directory with the DIR command by adding "*"
> > wild card before, between and after any number of fragments of the
> > whole name.
>
> Yes, just like a real command shell.
>
> Since you're so easily impressed, check out the /S option. That allows you
> to do a search on a whole tree. for example:
>
> cd /d c:\
> dir *.pdf /s
>
> will list all PDF files anywhere on the C: drive. And you can type that a
> lot faster than clickety-clicking your way thru the menus to do the
> corresponding FIND.
On October 16, 2005 06:00 pm, Russell McMahon wrote:
> > "*" is wildcard. For DOS filenames it is everything after from
> > the *
> > to the extension, then if you use * on the extension, it is
> > everything
> > from that point on, so:
>
> Not any more :-)
> Which is why I started this thread.
This is definitely off-topic for this thread, but another "charming"
feature is diacritics, where the keyboard substitutes 'a with the
accented a.... etc. It works in OS/2 and possibly also in windows too
(but haven't tried to see if it does work in windows). Charming at
1st, but for programmers it sort of gets in the way when it substitutes
programming code with accented stuff when you meant otherwise.
> In "real" DOS it WAS indeed EVERYTHING after *.
Well, (is it real? or is it memorex? hahaha) if it's useful, then it's
worth having then.
Usual gripes are if it breaks previous programs, but I don't think it
might in this case.
Russell McMahon wrote:
> I have never seen anything that describes this capability of DIR in a
> Windows DOS box and it's certainly not in the basic help. Which
> doesn't mean that many people haven't been using it for the last 10
> years.
It's the way other operating system file name wildcards work, so it's the
first assumption for anyone who wasn't that familiar with DOS. As far as I
know, this has always been part of CMD.EXE. According to your experience
this was apparently broken in COMMAND.COM, which doesn't surprise me because
that was the worst command shell ever written. CMD.EXE is a lot better, but
probably still a good candidate for second worst. For example, you can't
even set a shell variable to the one line standard output produced by a
program.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
> You are correct. Pipe is the | char.
> For further info:
[...]
> ">>" is used to append, so if you have a log file, you can append more
> to it.
>
> "2>" is normally standard error output "stderr".
> I believe DOS just uses stdout in this case.
It would probably be useful if we started to differentiate between the
various command processors. The "DOS box" in Windows doesn't necessarily
have much to do with MS-DOS, other than that a few basic commands are
similar (depending on the version of Windows).
Up until Win9x, the standard command processor was command.com, and I think
it was similar between the later versions of MS-DOS/Windows. But with Win2k
and WinXP, even though command.com is still present (probably for
compatibility reasons), what most people refer to as "DOS box" or so is
cmd.exe -- which has some of the same commands, but is a quite different
thing.
Regarding supported I/O redirection in cmd.exe (no clue how much of this
works with command.com):
"<file" : read stdio from a file
">file" or "1>file" : send stdout to a file
">>file" or "1>>file" : append stdout to a file
"2>file" : send stderr to a file
"2>>file" : append stderr to a file
">file 2>&1" : send both stdout and stderr to the same file
">>file 2>&1" : append both stdout and stderr to the same file
"cmd1 | cmd2" or "cmd1 0> cmd2" : pipe stdout of cmd1 to stdin of cmd2
paradise.net.nz> wrote:
