info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Is there a way to turn a folder's filenames into a text file?
11 views
Skip to first unread message
J. P. Gilliver (John)
Nov 4, 2017, 10:31:34 AM11/4/17
to
In message <gslqvct5h62cotro4...@4ax.com>,
gfre...@aol.com writes:
>On Fri, 03 Nov 2017 23:05:00 -0600, ja...@nospam.com wrote:
>
>>On Fri, 03 Nov 2017 20:39:34 -0400, Nil
>><redn...@REMOVETHIScomcast.net> wrote:
>>
>>>On 03 Nov 2017, ja...@nospam.com wrote in
>>>microsoft.public.windowsxp.general:
>>>
>>>> Aside from writing all of this on paper (too much work), is there
>>>> some software (freeware if possible) that can turn the filenames
>>>> in any folder into a text file, which I can save and have with me
>>>> at the WIFI.
>>>>
>>>> I recall in the DOS days I could make such a filename list using
>>>> the ">" after typing DIR. (I sort of forgot exactly how to do
>>>> that).
>>>>
>>>> But that will only generate trunkated 8+3 filenames.
>>>
>>>XP (and later)'s DOS emulation command line box will give you long file
[]
>>I'm using my Win98 computer right now. That does not work in Win98. I
>>get the 8+3 filenames. I will try it on my XP machine when I turn it on.
>>
Nil did say "XP (and later)" (-:
>
>It works on my w/98 machine.
That's interesting.
>Were these stored with 8.3 file names for
>some reason?
All files have an 8.3 filename (and can be accessed by it). Up to I
think '98 (probably Me too), you could see it in I think "Properties"
for the file, but for some reason best known to MS they removed that
from XP on; "dir /x" will show them, though.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf
The average US shareholding lasts 22 seconds. Nobody knows who invented the
fire hydrant: the patent records were destroyed in a fire. Sandcastles kill
more people than sharks. Your brain uses less power than the light in your
fridge. The Statue of Liberty wears size 879 shoes.
- John Lloyd, QI supremo (RT, 2014/9/27-10/3)
gfre...@aol.com writes:
>On Fri, 03 Nov 2017 23:05:00 -0600, ja...@nospam.com wrote:
>
>>On Fri, 03 Nov 2017 20:39:34 -0400, Nil
>><redn...@REMOVETHIScomcast.net> wrote:
>>
>>>On 03 Nov 2017, ja...@nospam.com wrote in
>>>microsoft.public.windowsxp.general:
>>>
>>>> Aside from writing all of this on paper (too much work), is there
>>>> some software (freeware if possible) that can turn the filenames
>>>> in any folder into a text file, which I can save and have with me
>>>> at the WIFI.
>>>>
>>>> I recall in the DOS days I could make such a filename list using
>>>> the ">" after typing DIR. (I sort of forgot exactly how to do
>>>> that).
>>>>
>>>> But that will only generate trunkated 8+3 filenames.
>>>
>>>XP (and later)'s DOS emulation command line box will give you long file
[]
>>I'm using my Win98 computer right now. That does not work in Win98. I
>>get the 8+3 filenames. I will try it on my XP machine when I turn it on.
>>
Nil did say "XP (and later)" (-:
>
>It works on my w/98 machine.
That's interesting.
>Were these stored with 8.3 file names for
>some reason?
All files have an 8.3 filename (and can be accessed by it). Up to I
think '98 (probably Me too), you could see it in I think "Properties"
for the file, but for some reason best known to MS they removed that
from XP on; "dir /x" will show them, though.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf
The average US shareholding lasts 22 seconds. Nobody knows who invented the
fire hydrant: the patent records were destroyed in a fire. Sandcastles kill
more people than sharks. Your brain uses less power than the light in your
fridge. The Statue of Liberty wears size 879 shoes.
- John Lloyd, QI supremo (RT, 2014/9/27-10/3)
Bill in Co
Nov 4, 2017, 3:46:30 PM11/4/17
to
Lee
Nov 4, 2017, 7:35:01 PM11/4/17
to
On Saturday, November 4, 2017 at 8:31:34 AM UTC-6, J. P. Gilliver (John) wrote:
> In message <gslqvct5h62cotro4...@4ax.com>,
> gfre...@aol.com writes:
> >On Fri, 03 Nov 2017 23:05:00 -0600, ja...@nospam.com wrote:
> >
> >>On Fri, 03 Nov 2017 20:39:34 -0400, Nil
> >><redn...@REMOVETHIScomcast.net> wrote:
> >>
> >>>On 03 Nov 2017, ja...@nospam.com wrote in
> >>>microsoft.public.windowsxp.general:
> >>>
> >>>> Aside from writing all of this on paper (too much work), is there
> >>>> some software (freeware if possible) that can turn the filenames
> >>>> in any folder into a text file, which I can save and have with me
> >>>> at the WIFI.
> >>>>
> >>>> I recall in the DOS days I could make such a filename list using
> >>>> the ">" after typing DIR. (I sort of forgot exactly how to do
> >>>> that).
> >>>>
> >>>> But that will only generate trunkated 8+3 filenames.
> >>>
> >>>XP (and later)'s DOS emulation command line box will give you long file
> []
> >>I'm using my Win98 computer right now. That does not work in Win98. I
> >>get the 8+3 filenames. I will try it on my XP machine when I turn it on.
> >>
98 Windows DOSbox produces a directory listing with BOTH every time.
> In message <gslqvct5h62cotro4...@4ax.com>,
> gfre...@aol.com writes:
> >On Fri, 03 Nov 2017 23:05:00 -0600, ja...@nospam.com wrote:
> >
> >>On Fri, 03 Nov 2017 20:39:34 -0400, Nil
> >><redn...@REMOVETHIScomcast.net> wrote:
> >>
> >>>On 03 Nov 2017, ja...@nospam.com wrote in
> >>>microsoft.public.windowsxp.general:
> >>>
> >>>> Aside from writing all of this on paper (too much work), is there
> >>>> some software (freeware if possible) that can turn the filenames
> >>>> in any folder into a text file, which I can save and have with me
> >>>> at the WIFI.
> >>>>
> >>>> I recall in the DOS days I could make such a filename list using
> >>>> the ">" after typing DIR. (I sort of forgot exactly how to do
> >>>> that).
> >>>>
> >>>> But that will only generate trunkated 8+3 filenames.
> >>>
> >>>XP (and later)'s DOS emulation command line box will give you long file
> []
> >>I'm using my Win98 computer right now. That does not work in Win98. I
> >>get the 8+3 filenames. I will try it on my XP machine when I turn it on.
> >>
True DOS mode can't do long filenames unless you use special addon commands written to do expressly that. Collectively they are called LFN tools and bring long file names to true DOS mode - you don't get that with 9x MS-DOS as installed at all. Even in Windows DOSbox situation if you want to access a file by it's long filename you will have to use quotes around it or the DOSbox emulator will trigger on the first 'word' only.
>
> >Were these stored with 8.3 file names for
> >some reason?
>
A quite simple registry addition will make a text file from any folder's content quite easily. Copy and paste the text below into a blank notepad document with two blank lines following the outlined text below (do not include the lines) and save it as dir.reg. Then double click it and answer yes to merge with registry. Reboot, from now on your right click menu will include a DirPrint option and when you select it, the folder's directory listing will be written to C:\ADIR.TXT where you can open it and print it if so desired. That file will be overwritten without notice when the option is selected again so if it's content is valuable then you should move it somewhere safe PDQ.
----------------------
REGEDIT4
[HKEY_CLASSES_ROOT\Folder\shell\DirPrint]
@="&DirPrint"
[HKEY_CLASSES_ROOT\Folder\shell\DirPrint\command]
@="Command.com /C DIR %1 /a /o:gne>C:\\ADIR.TXT"
----------------------
Since this approach uses 9x's DOS emulator as in a DOSbox situation, you will have BOTH the short 8.3 name and the long filename if it even exists.
There simply is no need for short filenames in NT, that command processor/emulator is long file name enabled from the start and doesn't even use the short form because it's not 8.3 limited DOS at all. It's an emulator from the start that is only made to look like DOS. Ironical enough NT batch is supremely powerful compared to 9x capabilities.
J. P. Gilliver (John)
Nov 4, 2017, 9:47:03 PM11/4/17
to
In message <fd0920b0-59eb-49af...@googlegroups.com>, Lee
<mel...@my-deja.com> writes:
[]
whose files it lists?
[]
2010-10-18, 9:xx.]
<mel...@my-deja.com> writes:
[]
>A quite simple registry addition will make a text file from any
>folder's content quite easily. Copy and paste the text below into a
>blank notepad document with two blank lines following the outlined text
>below (do not include the lines) and save it as dir.reg. Then double
>click it and answer yes to merge with registry. Reboot, from now on
>your right click menu will include a DirPrint option and when you
>select it, the folder's directory listing will be written to
>C:\ADIR.TXT where you can open it and print it if so desired. That file
>will be overwritten without notice when the option is selected again so
>if it's content is valuable then you should move it somewhere safe PDQ.
Thanks for this.
>folder's content quite easily. Copy and paste the text below into a
>blank notepad document with two blank lines following the outlined text
>below (do not include the lines) and save it as dir.reg. Then double
>click it and answer yes to merge with registry. Reboot, from now on
>your right click menu will include a DirPrint option and when you
>select it, the folder's directory listing will be written to
>C:\ADIR.TXT where you can open it and print it if so desired. That file
>will be overwritten without notice when the option is selected again so
>if it's content is valuable then you should move it somewhere safe PDQ.
>
>----------------------
>
>REGEDIT4
>
>[HKEY_CLASSES_ROOT\Folder\shell\DirPrint]
>@="&DirPrint"
>
>[HKEY_CLASSES_ROOT\Folder\shell\DirPrint\command]
>@="Command.com /C DIR %1 /a /o:gne>C:\\ADIR.TXT"
>
>
>----------------------
>Since this approach uses 9x's DOS emulator as in a DOSbox situation,
>you will have BOTH the short 8.3 name and the long filename if it even
>exists.
If you leave out the "C:\\", will it create ADIR.TXT in the directory
>----------------------
>
>REGEDIT4
>
>[HKEY_CLASSES_ROOT\Folder\shell\DirPrint]
>@="&DirPrint"
>
>[HKEY_CLASSES_ROOT\Folder\shell\DirPrint\command]
>@="Command.com /C DIR %1 /a /o:gne>C:\\ADIR.TXT"
>
>
>----------------------
>Since this approach uses 9x's DOS emulator as in a DOSbox situation,
>you will have BOTH the short 8.3 name and the long filename if it even
>exists.
whose files it lists?
[]
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf
Religion is a name for opinion that cannot be argued about. [Heard on Radio 4,
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf
2010-10-18, 9:xx.]
Lee
Nov 5, 2017, 1:38:35 AM11/5/17
to
R.Wieser
Nov 5, 2017, 2:19:34 AM11/5/17
to
John,
> If you leave out the "C:\\", will it create ADIR.TXT in the directory
> whose files it lists?
If it doesn't, try this:
>@="Command.com /C DIR %1 /a /o:gne>%1\..\ADIR.TXT"
(thats a slash, two dots and a slash)
Regards,
Rudy Wieser
> If you leave out the "C:\\", will it create ADIR.TXT in the directory
> whose files it lists?
>@="Command.com /C DIR %1 /a /o:gne>%1\..\ADIR.TXT"
(thats a slash, two dots and a slash)
Regards,
Rudy Wieser
Lee
Nov 5, 2017, 7:43:45 AM11/5/17
to
@="Command.com /C DIR %1 /a /o:gne>%1\\..\\ADIR.TXT"
since this is a registry file and two backslashes are needed to equate down to a single backslash for DOS operations - I think.
Looking at the actual value in regedit would show your text as given but the merging of a .reg file causes two backslashes to equal one. I dunno why, just something I've noticed. Sort of like in a batch file when you want %1 done there you need to actually write %%1 when it's done from a batch file only. Again dunno why exactly.
Not remembering all the shortcut scripts but wouldn't that equate to the root drive of the target folder? Something like that is bubbling in the back of my mind anyway.
R.Wieser
Nov 5, 2017, 8:37:04 AM11/5/17
to
Lee,
> May need: [snip]
You're right. I forgot that was ment for a .REG file. :-\ :-)
> would show your text as given but the merging of a .reg file causes
> two backslashes to equal one. I dunno why, just something I've noticed
The backslash is used as an so-called "escape" character. It is used to
mark certain characters (stored in a .REG file) as being used as literals.
Like an embedded double-quote (like in [program.exe "%1"]) being preceeded
by an escape-character, to indicate it should not be regarded as a special
character (end of a string here).
Example: "program.exe \"%1\""
> Not remembering all the shortcut scripts but wouldn't that equate
> to the root drive of the target folder?
Nope. :-)
The dot-dot is used with the DOS CD command to go one directory up, or when
provided in a path string, to remove the path-element just before it.
Regardless of, and that is the "trick", if that path-element points to a
folder or a file.
In other words:
"drive:\folder\filename\.."
will resolve to
"drive:\folder"
Oh blimey! I just realized that I'm trying to remove a file specification
where there most likely is none ... What I suggested would place the output
file in the parent of the folder which files are listed. :-(
.. and I realized something else: the %1 could well contain embedded spaces,
so it must be enclosed in double-quotes (for *both* usages of %1):
@="Command.com /C DIR \"%1\" /a /o:gne> \"%1\\ADIR.TXT\""
Regards,
Rudy Wieser
> May need: [snip]
You're right. I forgot that was ment for a .REG file. :-\ :-)
> would show your text as given but the merging of a .reg file causes
> two backslashes to equal one. I dunno why, just something I've noticed
mark certain characters (stored in a .REG file) as being used as literals.
Like an embedded double-quote (like in [program.exe "%1"]) being preceeded
by an escape-character, to indicate it should not be regarded as a special
character (end of a string here).
Example: "program.exe \"%1\""
> Not remembering all the shortcut scripts but wouldn't that equate
> to the root drive of the target folder?
The dot-dot is used with the DOS CD command to go one directory up, or when
provided in a path string, to remove the path-element just before it.
Regardless of, and that is the "trick", if that path-element points to a
folder or a file.
In other words:
"drive:\folder\filename\.."
will resolve to
"drive:\folder"
Oh blimey! I just realized that I'm trying to remove a file specification
where there most likely is none ... What I suggested would place the output
file in the parent of the folder which files are listed. :-(
.. and I realized something else: the %1 could well contain embedded spaces,
so it must be enclosed in double-quotes (for *both* usages of %1):
@="Command.com /C DIR \"%1\" /a /o:gne> \"%1\\ADIR.TXT\""
Regards,
Rudy Wieser
Lee
Nov 5, 2017, 8:00:52 PM11/5/17
to
Rudy,
On the same page now and that's the important part, thanks for the return message. I knew I had seen that before though and it was probably from within batch work coming from another batch which means %1 then and there resolves to the full filename and pathname of calling batch file itself and if you want to drop a result file in that folder you need to 'back up one' from that actual calling batch file and/or executable. And it makes good sense only now.
Windows DOSbox may be able to handle the expansion of %1 with spaces within but only actual testing would show and your quoting should otherwise provide protection from any space in such a pathname. I only gave it a couple shots and that does not qualify as 'testing' by any means. Unfortunately I wouldn't know what a literal was if it came up and bit me in the hindquarters - not your problem to explain either, I've tried many times before and no joy. I'm sure there many good sites to go look that up too, I'm just not in a mood to do that at the moment. For now I've made a mental note and it seems to be gelling somewhat - thanks.
On the same page now and that's the important part, thanks for the return message. I knew I had seen that before though and it was probably from within batch work coming from another batch which means %1 then and there resolves to the full filename and pathname of calling batch file itself and if you want to drop a result file in that folder you need to 'back up one' from that actual calling batch file and/or executable. And it makes good sense only now.
Windows DOSbox may be able to handle the expansion of %1 with spaces within but only actual testing would show and your quoting should otherwise provide protection from any space in such a pathname. I only gave it a couple shots and that does not qualify as 'testing' by any means. Unfortunately I wouldn't know what a literal was if it came up and bit me in the hindquarters - not your problem to explain either, I've tried many times before and no joy. I'm sure there many good sites to go look that up too, I'm just not in a mood to do that at the moment. For now I've made a mental note and it seems to be gelling somewhat - thanks.
R.Wieser
Nov 6, 2017, 2:56:04 AM11/6/17
to
Lee,
> I knew I had seen that before though and it was probably from within
> batch work coming from another batch
:-) I'm using it in the same way, for the same reason.
> %1 then and there resolves to the full filename and pathname of calling
> batch
> file itself
I think you ment %0 there ...
> I only gave it a couple shots and that does not qualify as 'testing' by
> any
> means
Another thing you can do: Open the registry and search for "%1" (without the
doublequotes -- or, now It think of it, with). You will find entries which
show them enclosed like that.
... But not always. It depends on the program and how it looks at its
arguments: If it only expects a pathname it will not even try to parse
anything, but will regard the whole argument string (including spaces and
other whitespace stuff) as a single argument. Other programs will accept
leading switches (mostly preceeded by a forward slash), but the moment it
doesn't find such a switch it regards the rest (upto the line end) as the
last, single argument.
But as rule-of-thumb, enclose path/filenames in doublequotes so you're not
caught with your pants down when either contains a space character. :-)
> Unfortunately I wouldn't know what a literal was if it came up and bit me
> in the hindquarters - not your problem to explain either
Same with me actually, I just knew about that backslash being an escape
character, and how to use it to embed doublequotes in a string.
What I normally do is to enter everything into the registry without
bothering about literals, and just let the registries export mechanism do
its work (and have it escape everything it thinks is neccesary).
Hey, I'm a hobby prorammer, I'm *expected* to be lazy like that. :-)
Regards,
Rudy Wieser
> I knew I had seen that before though and it was probably from within
> batch work coming from another batch
> %1 then and there resolves to the full filename and pathname of calling
> batch
> file itself
> I only gave it a couple shots and that does not qualify as 'testing' by
> any
> means
doublequotes -- or, now It think of it, with). You will find entries which
show them enclosed like that.
... But not always. It depends on the program and how it looks at its
arguments: If it only expects a pathname it will not even try to parse
anything, but will regard the whole argument string (including spaces and
other whitespace stuff) as a single argument. Other programs will accept
leading switches (mostly preceeded by a forward slash), but the moment it
doesn't find such a switch it regards the rest (upto the line end) as the
last, single argument.
But as rule-of-thumb, enclose path/filenames in doublequotes so you're not
caught with your pants down when either contains a space character. :-)
> Unfortunately I wouldn't know what a literal was if it came up and bit me
> in the hindquarters - not your problem to explain either
character, and how to use it to embed doublequotes in a string.
What I normally do is to enter everything into the registry without
bothering about literals, and just let the registries export mechanism do
its work (and have it escape everything it thinks is neccesary).
Hey, I'm a hobby prorammer, I'm *expected* to be lazy like that. :-)
Regards,
Rudy Wieser
Lee
Nov 6, 2017, 5:06:43 PM11/6/17
to
On Monday, November 6, 2017 at 12:56:04 AM UTC-7, R.Wieser wrote:
>
> I think you ment %0 there ...
>
Ah snap. Now you caught me asleep at the wheel.
>
> I think you ment %0 there ...
>
>
> ... But not always.
>
And therein lay the rub - exactly when is it 'not always'?
And no, 'when it isn't' is not much help. It is funny though.
>
> Same with me actually, I just knew about that backslash being an escape
> character, and how to use it to embed doublequotes in a string.
>
Thanks Rudy, it's been fun.
R.Wieser
Nov 7, 2017, 2:15:35 AM11/7/17
to
Lee,
> Ah snap. Now you caught me asleep at the wheel.
I have already bungled up twice now, so I'm the last one to judge. :-)
> And therein lay the rub - exactly when is it 'not always'?
When you run into it ofcourse ! :-D
But seriously, I've got, and *cannot* have any idea about that.
You see, its fully upto the person who writes the program to how to handle
the argument string. Yes, thats right: All you are getting is a single
string (from the 'GetCommandLine' function in Kernel32) you have to parse
yourself. Or depend on a programming-environments build-in handling of
that string, like happens within C{something}. But even that doesn't fix
everything.
I've got programs here which use "-" (instead of the windows "/") as a
switch prefix (probably because it was origionally a Linux based program),
programs which regard the whole argument string as path, others which
accepts switches but the moment it does not find such a switch takes the
rest of the line as a single argument. Yet others accept the next
(space-delimited) string after a switch (even when seperated by a space) as
an argument to that switch. And I'm sure that what I've encountered myself
is not even close to exhaustive ...
I short: 10 different programmers *could* mean 10 different ways the
arguments are parsed/looked at. :-\
> And that's my takeawsy lesson. .... Thanks Rudy, it's been fun.
Thanks for mentioning that. Although I always enjoy helping others by
explaining stuff like this, its nice to hear it once in a while. :-)
Regards,
Rudy Wieser
> Ah snap. Now you caught me asleep at the wheel.
> And therein lay the rub - exactly when is it 'not always'?
But seriously, I've got, and *cannot* have any idea about that.
You see, its fully upto the person who writes the program to how to handle
the argument string. Yes, thats right: All you are getting is a single
string (from the 'GetCommandLine' function in Kernel32) you have to parse
yourself. Or depend on a programming-environments build-in handling of
that string, like happens within C{something}. But even that doesn't fix
everything.
I've got programs here which use "-" (instead of the windows "/") as a
switch prefix (probably because it was origionally a Linux based program),
programs which regard the whole argument string as path, others which
accepts switches but the moment it does not find such a switch takes the
rest of the line as a single argument. Yet others accept the next
(space-delimited) string after a switch (even when seperated by a space) as
an argument to that switch. And I'm sure that what I've encountered myself
is not even close to exhaustive ...
I short: 10 different programmers *could* mean 10 different ways the
arguments are parsed/looked at. :-\
> And that's my takeawsy lesson. .... Thanks Rudy, it's been fun.
Thanks for mentioning that. Although I always enjoy helping others by
explaining stuff like this, its nice to hear it once in a while. :-)
Regards,
Rudy Wieser
0 new messages