system command, -Z Flag and quotes
Dennis Malen
dmalen at malen.com
Fri Jan 7 09:49:01 PST 2005
John,
You never cease to amaze me. Wow!!!!!
Your response is invaluable. That info should be in a manual. Your
information will be extremely helpful.
Thanks for taking the time to respond in such detail. I hope the rest of the
LIST appreciates your input.
Thanks so much.
Dennis
----- Original Message -----
From: "John Esak" <john at valar.com>
To: "Fplist (E-mail)" <filepro-list at seaslug.org>
Sent: Friday, January 07, 2005 12:15 PM
Subject: I'RE: system command, -Z Flag and quotes
> > Dennis Malen wrote:
> > > I believe this was discussed some time ago.
> > >
> > > I want to use the system command in a processing table using the "-Z"
> > > flag. The -Z would need quotes before and after. The following is the
> > > line needed but I don't know how to do with the quotes:
> > >
> > > system "/appl/fp/rclerk msx.served -s1 -z "addfile"
> > >
> > > system "/appl/fp/rclerk msx.served -s1 -z \"addfile\""
> > >
> > >
> >
> > You can insert quotes by putting \" instead of just "
> >
> > Nancy
>
> I hate to add to this thread at the very end of it (hopefully), but
everyone
> is forgetting to suggest that doing a "SYSTEM anything" is almost always
> better and easier accomplished as:
>
> SYSTEM variable
>
> Simply, fill in, concatenate, build into the variable everything you want
> the system command to do and then execute that variable with SYSTEM, as
in:
>
> then: declare SysCmd
> then: SysCmd="dreport" < filename < "-fp" < formatname < "-v" <
> vtablename < "-u -r" < r_value < "-rw" < rw_value ... (etc.)
> then: system SysCmd
>
> where the varying items are declared variables like formatname,
vtablename,
> etc. By building everything into a single variable (either 2 character
type,
> or declared type) things just go much easier.
>
> However, the real, more pressing problem with SYSTEM commands is "knowing"
> what they will look like before you actually send them to the operating
> system. FilePro first acts on them substituting values for fields, and
> doing the other translations it does to meta characters, etc. Then the O/S
> gets hold of it and does its magic. All in all, being able to see the
> "exact" non-translated, or "raw" string that you are really sending to the
> O/S is important. All of us have struggled with this for years since SHOW
> and MESGBOX will render the filePro version of things instead of the real
> unadulterated string. I usually quickly write the following code on the
fly
> to test complicated SYSTEM commands... after reading this thread, I
decided
> to once and for all throw it into my library so it can be used from any
file
> anywhere as a CALL table. I'll lay it all out here in very simple terms so
> even any beginners out there can try it out. It works very well to show
you
> a "what-you-see-is-what-you're-gonna-get" version of your SYSTEM commands.
> Enjoy.
>
> ===== How to show an unadulterated SYSTEM string. =====
>
> Define a filePro file called "showfile". Put only 1 field in it for a
length
> of 999 with no edit type. The fieldn name is unimportant. Create Screen
0.
> Go into Define Screens and put the one field on the screen as follows:
>
> SHOWFILE
> --------------------------------------------------------------------------
--
> -
> *1
>
>
> Then build a call table in your "library" filePro file called
> "call_shw_SysCmd" that looks
> like this:
>
>
> filePro File: library
> Processing Table: call_shw_SysCmd
> Last Modified: Friday - Jan 7, 2005 at 10:48 AM
> Documented: Friday - Jan 7, 2005 at 10:52 AM
>
> 1 Then: declare extern SysCmd
> 2 Then: lookup putinfile=showfile r=("1")
> If: not putinfile
> 3 Then: lookup putinfile=showfile r=free
> 4 Then: putinfile(1)=SysCmd
> 5 Then: popup putinfile,"0"; show "@"; end
>
>
> To test how this works put the following code in a test file and
> run it (by going into IUA on any record and pressing "T").
>
>
> filePro File: test
> Processing Table: input
> Last Modified: Friday - Jan 7, 2005 at 10:50 AM
> Documented: Friday - Jan 7, 2005 at 10:51 AM
>
> 1 Then: end
> @keyT If: '@keyT
> 2 Then:
> 3 Then: declare global SysCmd
> 4 Then: declare varjunk; varjunk="-h \r Running Report #1 \r"
> 5 Then: SysCmd="/usr/bin/this_and that/newline/stuff/doit" < varjunk
> 6 Then: call "/u/appl/filepro/library/call_shw_SysCmd"
> 7 Then: end
>
>
> You should get results like the following:
>
> TEST
> --------------------------------------------------------------------------
--
> -
> SHOWFILE
> --------------------------------------------------------------------------
--
> -
> /usr/bin/this_and that/newline/stuff/doit -h \r Running Report #1 \r
>
>
>
> --------------------------------------------------------------------------
--
> -
> Press Enter To Continue
>
>
> Normally, any SHOW or MESGBOX will render the \'s into their assigned
> functioniality and you won't really see the "raw" value of the SYSTEM
> string. In the
> above example, the heading would be shown in reverse video... In other
> cases, many things involving \'s get rendered, \n, \t, \", etc. This
makes
> it hard to figure out what is wrong when a command doesn't function
> properly. You have to be able to see the un-rendered string.
>
> By slowly and methodically building your SYSTEM command, and testing it
> frequently with this little call table you can put into any processing
> temporarilly, you _can_ really "see" what you are generating. Believe me
> your results will surprise you sometimes, and often you will catch errors
> in "data" based problems like having extra spaces in -r arguments or
> trying to translate dates with slashes in them into filenames... and all
> sorts of other unforeseen renderings.
>
> I realize there are probably several (hundred) better ways to do this
> clear showing of SYSTEM commands, and this offering here might seem
> cumbersome, but it works for me, it's in the library now that I've
> decided to put it up here in the forum, and what the hell, it's one
> less thing you have to figure out.
>
> I will say this... this tiny bit of code has helped me solve some very
> complex system routines which have several -r arguments and widely
> varying data being passed to them. Until you can actually see what
> they look like before filePro and the O/S get their hands on them, some
> SYSTEM commands will baffle you for hours... especially, when I see
> people talking about escaping quotes and, etc., which you so often have
> to do to get it right. Good luck.
>
> John Esak
>
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
>
>
More information about the Filepro-list
mailing list