shell statement help!!

[Raed Abu-Sanad]

hhi,
could plz interpret this command line to me:

SHELL ENVIRON$("COMSPEC") + " /C DIR   *.* > filename.txt

it seems vague to me.(i got it from the windows online help)

thanks

[Chris Holbrook]

hhi,
could plz interpret this command line to me:

SHELL ENVIRON$("COMSPEC") + " /C DIR   *.* > filename.txt

it seems vague to me.(i got it from the windows online help)

thanks

It is calling the command interpreter whose path is given by the environment variable "COMSPEC" with the parameter "/C" to exeucte a DIR command and create or overwrite a file called filename.txt with the results.

[Michael Mattias]

http://technet.microsoft.com/en-us/library/bb490982.aspx

[Vidar Hanto]

SHELL ENVIRON$("COMSPEC") + " /C DIR   *.* > filename.txt

When working with file redirection (the ">" char is file redirection as shown in MCM's link above) beware that it may be important to get your SPACE characters right.

It's been a long time since I did a serious Batch-file, but if memory serves me right the following is true (not tested at this time, though):
Back in time before leaving Windows 3.x (= DOS), the rule was to put ">" immediately after the last charcter _needed_. In some cases it wouldn't matter due to the command's nature (e.g. DIR *.* as above), but it would never be wrong. As to the SPACE following ">" DOS wouldn't bother. Do as you wish.

E.g., take a look at the files resulting from:

echo Hello!>File1.txt
echo Hello! >File2.txt
echo Hello!> File3.txt
echo Hello! > File4.txt

or, if you wish:

SHELL ENVIRON$("COMSPEC") + " /C echo Hello!> File1.txt"
SHELL ENVIRON$("COMSPEC") + " /C echo Hello! >File2.txt"
SHELL ENVIRON$("COMSPEC") + " /C echo Hello!> File3.txt"
SHELL ENVIRON$("COMSPEC") + " /C echo Hello! > File4.txt"

After the introduction of Win95 and WinNT4 (I've never used WinNT3.x for anything serious) things changed. You sometimes had to insert a SPACE prior to ">", and sometimes also following ">". It would change behaviour with the OS, and you had to test carefully what to do (=ID your OS) prior to issuing the command.

The importance of the SPACE depends on the output of the command issued and what you need to collect. What the current status of this is, I do not know. But - depending of your needs - you could be in for some hard-to-crack surprises.

x-BATMAN

[Michael Mattias]

>SHELL ENVIRON$("COMSPEC") + " /C DIR *.* > filename.txt

Actuallly, the correct code would be:

 LOCAL hFile AS LONG, S AS  STRING 
 Hfile = FREEFILE
 OPEN "Filename.txt" FOR OUTPUT AS hFile 
 S = DIR$("*.*") 
 WHILE LEN(S) 
     PRINT #hFIle, S
     S = DIR$
 WEND 
 CLOSE hFile
 DIR$ CLOSE

(if you need file sizes and dates, there are ways to do that fairly easily, too).

MCM

[John Petty]

>Actuallly, the correct code would be:
MCM

Accoriding to the local guru this might have been better worded "application specific but no detalis posted so here is another option"
After all he is always so helpful to new users

[Michael Mattias]

I continue to be amazed at how many people SHELL to get a directory list, or make a file copy when either one takes maybe ten lines of code and you never spend so much as five seconds screwing around with "ENVIRON$()" or "CMD /C" or spaces in filenames, etc...

[Michael Mattias]

Speaking of which... here's a fairly decent demo of getting a directory list

Directory List with Non-ASCII (Unicode) characters in file names 5-31-08

Works with either PB/Win or PB/CC "out of the box" (i.e cut and paste)

[Joe Byrne]

I continue to be amazed at how many people SHELL to get a directory list, or make a file copy when either one takes maybe ten lines of code and you never spend so much as five seconds screwing around with "ENVIRON$()" or "CMD /C" or spaces in filenames, etc...

Ah, perhaps because using the shell command takes one line of code?

What does "screwing around with" mean? If I use sf = DIR$(Mask, %SUBDIR)
am I screwing around with the DIR$ command?

I continue to be amazed at how many people ..... ah, never mind.

[Michael Mattias]

No, the screwing around I am talking about is the

- using redirection operators (> or <).. and remembering to use CMD or ENVIRON$("COMMAND") .. or is it ENVIRON$("CMD")?

- Figuring out when to quote filenames because they contain spaces.

Besides, in the example given here... one line of "SHELL" clearly does you no good... unless you are creating that file just so that it exists. Presumably there is going to be an OPEN, LINE INPUT, parse (generically, not the function/statement) and CLOSE sequence to actually "do something" with the data.

I'd be really surprised if not everyone has some kind of

FUNCTION GetDirList (mask, Fname())  AS LONG

.. to return a directory list into a string array and some kind of "append file" function in their personal code library.

"COPY" of course is handled by the intrinsic "FILECOPY" function.... ooh, ooh, wait a sec... let me check the 9x help to see if it's in there...nah, it's not. Bummer. I have an NFS in for:

FILECOPY  src, target [,APPEND]

.. but I guess that didn't make the cut.

Neither did SIZEOF(datatype), eg, SIZEOF(LONG)

But lots of other good stuff. I really like the callback option for ARRAY SORT. (But I already sent in a NFS to upgrade that... to add an "lparam/dwuser" which would be passed to the callback function).

MCM

[Michael Mattias]

FWIW, the demo linked above includes the "GetDirList()" function mentioned.. two of them in fact, one in ANSI and one in Unicode.

[Joe Byrne]

Michael,

There are many ways to skin the proverbial cat, and whether one method is "better" than another is strictly a matter of opinion. If the 'shell' command works, its probably easier to use for someone new so a case could be made for its use. Some people might not have a problem remembering whether its "CMD or ENVIRON$("COMMAND") .. or is it ENVIRON$("CMD")" therefore making this method, again, "just as good" from the standpoint of 'working'

There's surely nothing wrong with showing alternative methods, but, IMO, its not very beneficial to the someone just starting out to tell them, in so many words, that their method is wrong when clearly, "wrong" is simply a subjective argument.

Of course, the real fact is that the original question was not even asking "if it works/is there a better way", but "how does this code work".

[Cliff Nichols]

Neither did SIZEOF(datatype), eg, SIZEOF(LONG)

Ummmm, either that has existed for a LONNNNNNNG time with the idea of

LOCAL MyVariable as LONG
SIZEOF(MyVariable)

Or did you want to skip one line of code and use "SIZEOF(LONG)" ??????

[Michael Mattias]

>Or did you want to skip one line of code and use "SIZEOF(LONG)" ??????

Exactly.

It makes code more self-documenting if you are doing your own memory allocations.
eg

pMem =   malloc (n*4)    ' allocate space for 'n' long integers 
or 
pMem =   malloc (n*SIZEOF(LONG))    ' comment kind of redundant now, huh?

MCM