shell "dir *.* > list.txt"

[Alan Hanson]

I am having problems using powerbasic to sort some files. The files have loing file names and what I am trying to do is generate a list of the files with a given string in them. Regardless of whether I do
shell "dir 12345*.txt /b > list" or shell to a batch file with the same dir command in it the long file names are returned in the short file name format. When I execute the batch file from the command prompt I get the long file names as expected.
I saw a similar post http://www.powerbasic.com/support/pb...long+file+name where someone was having a similar problem but the replies to the post didn't help me as I couldn't get the replies to work.
I am using windows xp and eventually I want to be able to get the following dir command to work
dir *12345*54321*.txt > list.txt
I would prefer it to work from a shell command but if i have to run in from a shelled batch file i could live with that too.

Thanks in advance

[Michael Mattias]

You want long names?
Then use a DIR option which returns long names.

C:\DOS> dir /? | more

[John Montenigro]

You might need to use the /N switch, which puts the long filenames to the right of the date/time...
???
-John

[Michael Mattias]

>You might need to use ...

...something suggested by the help ("DIR /?") ?????

[Alan Hanson]

I am after the long file names.
To the best of my knowledge it isn't my usage of the DIR command. It is something to do with the way that powerbasic interfaces with DOS in the shell mode.
Both at the command prompt and in a batch file DIR /b *.* > list.txt will give me a list with long file names. However when I try doing it from a shell it changes them to short file names .

[Mel Bishop]

If I'm reading you right, this might help:

http://www.powerbasic.com/support/pbforums/showthread.php?t=23451

[John Montenigro]

>You might need to use ...

...something suggested by the help ("DIR /?") ?????

No. It was suggested by years of experience with DOS, and the transition to Windoze that occurred circa 1995... I didn't need to look this one up.

When I first got XP, I set the DIR command permanently to "/N" (although I can't for the life of me remember now how I did that). To see the old, original format, I use: DIR /-N

[John Montenigro]

I am after the long file names.
To the best of my knowledge it isn't my usage of the DIR command. It is something to do with the way that powerbasic interfaces with DOS in the shell mode.
Both at the command prompt and in a batch file DIR /b *.* > list.txt will give me a list with long file names. However when I try doing it from a shell it changes them to short file names .

IIRC, the /B switch will interfere with the long filenames you can get via the /N switch.

I don't recall the /B switch having much value...

[Hubert Brandel]

Hi,

if I

 shell "dir *.* /N"

I will get a error that /N is not allowed. When I start it direktly in the CMD it works. So I think you can't use a DOS Programm to get the long names.

But you can make a CMD file, first build the textfile with dir ... and then read the textfile with your dos programm.

[John Montenigro]

What about:

shell "cmd /c dir /N *.*"

[Dave Biggs]

When I first got XP, I set the DIR command permanently to "/N" (although I can't for the life of me remember now how I did that). To see the old, original format, I use: DIR /-N

Possibly you set DIRCMD /N in System Properties / Advanced / Environmental Variables ?

You can override with /-N (as you said).

PB Statement ENVIRON$ can be used to check the current setting.

[Alan Hanson]

Thanks for the help guys. After trying heaps of combinations I got the following to produce the desired results.
shell "cmd /c dir *12345*.* /b"
I'm not sure what the cmd /c does but it did the trick

[Arthur Gomide]

> ... I'm not sure what the cmd /c does but it did the trick

Try

Start, Run..., cmd /k

and then

cmd /?

to see the small help!

[Vidar Hanto]

I do not have PB DOS available now, so I cannot check it all out, but I suspect this is why this happens (consider this as speculation, but it will explain why):

PB DOS's 'shell "dir *.* > list.txt"' will expect a 16-bit DOS shell as it has its roots in the 16-bit, 8.3 character file name world of MS. So it either has its own built-in 16-bit COMMAND.COM clone in order to speed things up or it will start the current COMMAND.COM shell - which may or may not support LFN. In the W9x world COMMAND.COM supports LFN, as will COMMAND.COM in the WNT+ world. No matter how - you're at the shell's (COMMAND.COM's) mercy, but above DOS 6.x they should still support LFN.

I doubt - due to PB's strong no bloatware policy - that PB has implemented its own full COMMAND.COM. I do think it is more probable that PB DOS has implemented its own version of the most-often-used DOS shell commands (where "dir" certainly belongs) and would start COMMAND.COM for other uses, e.g. if you were to start a BATCH file. If this is what is being done, it increase speed and reduce bloatware - at the cost of [future] compatibility in the 'dir'-command's case.

If you specify the shell to use, you are free to specify one that do support LFN - and CMD.EXE under WNT+ will. So, by specifying

'shell "CMD.EXE /c dir *.* > list.txt"

you basically tell PB DOS to start CMD.EXE and then issue whatever command you specify for CMD.EXE to execute. And this does the trick. Shelling to COMMAND.COM using the same parametres should do the same trick in dir's case, and it will be compatible with W9x and DOS as well (but below W9x LFN will not be supported, of course - but there's things like FreeDOS that do).

Also, if you are SHELLing often enough, you should take the time to check out what CMD.EXE (or COMMAND.COM) can and cannot do for you. Start a console window and issue the "CMD.EXE /?" command to get to the help-screen. It will also explain the "/C"-switch which is crucial in this context.

ViH

[John Montenigro]

Possibly you set DIRCMD /N in System Properties / Advanced / Environmental Variables ?
...
PB Statement ENVIRON$ can be used to check the current setting.

Nope. No DIRCMD showing with either: SET from a CMD window, nor a PB loop through ENVIRON$. Not under ControlPanel>Environment Variables. No special settings in my shortcuts for CMD, either, and I've made no mods to AUTOEXEC.NT

I searched the registry for DIRCMD, DIR /N, and COMMAND PROCESSOR, but none of them showed anything...

Now I'm stumped - where could that setting be?

Just out of curiosity, what is the default for DIR under XP? Short names to the left of the date/time, or long names to the right?

Maybe I'm remembering using /-n for the old DOS-style...

[John Montenigro]

Thanks for the help guys. After trying heaps of combinations I got the following to produce the desired results.
shell "cmd /c dir *12345*.* /b"
I'm not sure what the cmd /c does but it did the trick

While SHELL does run a command processor, I seem to recall that as far back as DOS, "first level" command processors sometimes have problems with control and communication back to the parent, whereas their children don't. So as a workaround/hack, we often just used the first-level cp to invoke a child cp, and ran the command there. Especially if we knew it would not require user interaction, and would only perform limited work.

All that "cmd /c" does is to start another command processor and the /c switch instructs it to terminate when the command it's running is finished. (Another switch, /K, also invokes a secondary processor, but it does NOT self-terminate when the command it's running is finished.)

In the Help file under DIR, see "Restrictions" - it mentions that DIR is an internal DOS command and SHELL needs to see the /C switch. It's actually shown in the Example, too.

[Arthur Gomide]

If you want a 16-bit COMMAND.COM (MS-DOS), the XP has one - at least in the Brazilian version!

Try,

Start, Run.., cmd /k

and then

command /k

dir (see the difference!)

exit (to leave the MS-DOS command)

and now

exit (to leave the XP cmd)

But note - not all functions are listed with command /? - they work /b, /n, /k but are not listed.