Announcement

Collapse
No announcement yet.

shell statement help!!

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • shell statement help!!

    hhi,
    could plz interpret this command line to me:

    Code:
    SHELL ENVIRON$("COMSPEC") + " /C DIR   *.* > filename.txt
    it seems vague to me.(i got it from the windows online help)

    thanks

  • #2
    Originally posted by Raed Abu-Sanad View Post
    hhi,
    could plz interpret this command line to me:

    Code:
    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.

    Comment


    • #3
      http://technet.microsoft.com/en-us/l.../bb490982.aspx
      Michael Mattias
      Tal Systems Inc. (retired)
      Racine WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        Originally posted by Raed Abu-Sanad View Post
        Code:
        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:
        Code:
        echo Hello!>File1.txt
        echo Hello! >File2.txt
        echo Hello!> File3.txt
        echo Hello! > File4.txt
        or, if you wish:
        Code:
        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

        Comment


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

          Actuallly, the correct code would be:
          Code:
           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
          Michael Mattias
          Tal Systems Inc. (retired)
          Racine WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            Originally posted by Michael Mattias View Post
            >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

            Comment


            • #7
              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
              Tal Systems Inc. (retired)
              Racine WI USA
              [email protected]
              http://www.talsystems.com

              Comment


              • #8
                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)
                Michael Mattias
                Tal Systems Inc. (retired)
                Racine WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  Originally posted by Michael Mattias View Post
                  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.
                  Software makes Hardware Happen

                  Comment


                  • #10
                    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
                    Code:
                    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:
                    Code:
                    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
                    Tal Systems Inc. (retired)
                    Racine WI USA
                    [email protected]
                    http://www.talsystems.com

                    Comment


                    • #11
                      FWIW, the demo linked above includes the "GetDirList()" function mentioned.. two of them in fact, one in ANSI and one in Unicode.
                      Michael Mattias
                      Tal Systems Inc. (retired)
                      Racine WI USA
                      [email protected]
                      http://www.talsystems.com

                      Comment


                      • #12
                        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".
                        Software makes Hardware Happen

                        Comment


                        • #13
                          Neither did SIZEOF(datatype), eg, SIZEOF(LONG)
                          Ummmm, either that has existed for a LONNNNNNNG time with the idea of
                          Code:
                          LOCAL MyVariable as LONG
                          SIZEOF(MyVariable)
                          Or did you want to skip one line of code and use "SIZEOF(LONG)" ??????
                          Engineer's Motto: If it aint broke take it apart and fix it

                          "If at 1st you don't succeed... call it version 1.0"

                          "Half of Programming is coding"....."The other 90% is DEBUGGING"

                          "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                          Comment


                          • #14
                            >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
                            Code:
                            pMem =   malloc (n*4)    ' allocate space for 'n' long integers 
                            or 
                            pMem =   malloc (n*SIZEOF(LONG))    ' comment kind of redundant now, huh?
                            MCM
                            Michael Mattias
                            Tal Systems Inc. (retired)
                            Racine WI USA
                            [email protected]
                            http://www.talsystems.com

                            Comment

                            Working...
                            X