× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Scott wrote:

> According to the documentation to the QzshCheckShellCommand() API:
> 
>     The QzshCheckShellCommand() function finds the specified shell command
>     by searching:
> 
>         * for a built-in utility, then
>         * in each directory in the list specified by path or the PATH
>             environment variable in turn.
> 
>     An application can use QzshCheckShellCommand() to verify that command
>     exists and the user has authority to command before running it.
> 
> This seems to match exactly your experiences.  It says that it searches
> for a command called 'ls' in the paths specified in the 2nd parm.   That
> works, because it finds a command called 'ls'
> 
> In your second example, it's looking for a command called 'ls -l'.  There
> is no command by that name (and there shouldn't be!!!) so the API is
> worked as designed.
> 
> You seem to expect QzshCheckShellCommand() to validate the syntax of
> the parameters of the command -- it doesn't do that.  It just looks for
> a command.   It is valid in Unix (but a bad idea!) for command names to
> have spaces in them.
> 

All valid points: I reverted to the ls example because that is about as
basic as it gets.  I was merely sharing the fact that ls -l didn't work,
and it makes perfect sense to me that it does not.  So I'll concede that
the CheckShellCommand API is working as designed.


> > Unfortunately I need to get this done, so I guess I'll have to try to
> > issue the command the old fashioned way with system or QCMDEXC.  The
> > problem is that when I do that within a program the user is prompted to
> > press Enter to close the shell.  I need to make this transparent to the
> > user, but the command doesn't appear to have a 'quiet' mode.
> 
> Well, for mkdir you could just use the API... that'd be much easier...

If the API worked to issue the mkdir command then this entire thread
would never have started.  I began by using QzshSystem() to try and
simply create a directory.

// some good stuff deleted

> In order to make it run without using STRQSH, you'd have to set up the
> descriptors 0,1,2 which are expected to always work for a Unix program.
> RPG doesn't do that for you by default (though, ILE C or Java probably do)

Now I think we're getting somewhere.  I stupidly assumed that the API
would handle the necessary grunt work so that I could issue QSH
commands.
> 
> Here's a message that I posted in the past that relates to dealing with
> opening those descriptors.  In fact, you may find that entire thread
> to be instructive.
>    http://archive.midrange.com/rpg400-l/200204/msg00195.html

I read that post prior to starting this thread but I thought you were
trying to write to standard out specifically, and since I didn't need to
do that (or so I thought) I didn't try to implement that.  I'll be back
at the drawing board after this to figure that otu.

> > This is really getting frustrating for something that should be
> > simple...
> 
> Keep in mind that you're trying to use a programming language that doesn't
> exist in Unix environments to run Unix commands on a non-Unix system.
> It doesn't seem to me that it should be simple.  (Though, it'd be nice if
> it were!)

Maybe I'm too basic for this work.  It doesn't matter to me if the
commands are Unix or not, in fact I think they should be native OS/400
commands.  Copying a directory and it's contents in a supported file
system from an application written in a native language should be easy,
period.  I'm using the Unix style commands and QSH because I have
basically no other option.

I think at this point my frustration level is high enough to call it a
day.  I'll get back to this tomorrow.

I really do appreciate everyone's input.

Thanks, 

Joel
http://www.rpgnext.com



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.