[Gambas-user] More Problems with SHELL (possible BUG).

[audiossis]

On Friday 06 July 2007 00:27:21 gambas-user-request at lists.sourceforge.net wrote:
> Message: 8
> Date: Thu, 5 Jul 2007 14:22:23 +0200
> From: Stefano Palmeri <rospolosco at ...152...>
> Subject: Re: [Gambas-user] More Problems with SHELL (possible BUG).
> To: mailing list for gambas users <gambas-user at lists.sourceforge.net>
> Message-ID: <200707051422.23963.rospolosco at ...152...>
> Content-Type: text/plain;  charset="iso-8859-1"
> 
> Alle 13:58, gioved? 5 luglio 2007, audiossis ha scritto:
> > Hello,
> >
> > I have noticed a problem with using the "SHELL" command to execute console
> > functions and then return the output of those functions to a "Process_read"
> > sub.
> > For the most part this seems to work quite well. When "rm" to remove files
> > or when using "cp" to copy files using the code:
> >
> > PUBLIC SUB something()
> >
> > SHELL "cp -var /some/directory/some/file /another/directory/another/place"
> > WAIT FOR READ
> >
> > END
> >
> > PUBLIC SUB Process_read()
> >
> > DIM sOut AS String
> > hStream = OPEN "/path/to/log/file" FOR APPEND
> >
> > READ #LAST, sOUT, -256
> > PRINT #hStream, sOUT
> >
> > END
> >
> >
> > The output of "cp" is returned and printed to the log file. However this is
> > not the case when using "mkdir" with the following code:
> >
> >
> > PUBLIC SUB something()
> >
> > SHELL "mkdir -v /new/directory" WAIT FOR READ
> >
> > END
> >
> > PUBLIC SUB Process_read()
> >
> > DIM sOut AS String
> > hStream = OPEN "/path/to/log/file" FOR APPEND
> >
> > READ #LAST, sOUT, -256
> > PRINT #hStream, sOUT
> >
> > END
> >
> >
> > This produces absolutely no output to the log file whatsoever. but if I
> > remove the "FOR READ" argument I can clearly see the output of the "mkdir"
> > in the GAMBAS console. The same can be said for using the "cpio" command to
> > create backup archives in the same manner. The command executes but "READ"
> > does not receive the output from the command therefore no output is made to
> > the log file.
> >
> > I have also noticed that using "cd" or "pushd" to traverse filesystems is
> > difficult at best from within GAMBAS. For example, if I use this code:
> >
> > SHELL "pushd /directory"
> > SHELL "find ./ | cpio -vco | gzip > /path/to/archive/file"
> >
> > Then the only files I get into my archive, are the GAMBAS files from the
> > directory where GAMBAS itself was executed.
> >
> > Unless you use these commands within the same "SHELL" statement as another
> > command like this:
> >
> > SHELL "pushd /directory; find ./ | cpio -vco | gzip >
> > /path/to/archive/file"
> >
> > You cannot traverse the filesystem to another directory. It seems that any
> > effect had by "pushd" or "cd" is undone as soon as the current "SHELL"
> > statement is finished and your current filesystem location returns to the
> > GAMBAS execution directory. I must say that this is most frustrating when
> > combined with the other problems outlined above.
> >
> >
> >
> > Does anyone have any ideas about how to get around any of these issues?
> >
> > Oh and by the way "EXEC" does not seem to return ANY command output
> > at all to the "FOR READ" argument, regardless of which command is executed
> > on the console.
> >
> >
> > Any help or work suggestions at all would be greatly appreciated!
> >
> > Ben Phillips
> > audiossis at ...867...
> >
> 
> Hi.
> 
> it seems that mkdir doensn't print messages on standard output
> 
> try SHELL "mkdir -v /new/directory >&1" WAIT FOR READ
> 
> and see if it works.
> 
> Stefano

Thanks Stefano for your suggestion but unfortunately I have to report that it made no difference.
I should at this point mention that I have tried re-directing the output  of both "mkdir" and "cpio" by using code like:

SHELL "mkdir -v /new/directory >/dev/stdout" WAIT FOR READ

and

SHELL "mkdir -v /new/directory >/dev/console" WAIT FOR READ


Your suggestion made sense but I don't think that the problem lies with the direction (or lack thereof) of output from the shell programs but rather the
content of their returns. I wonder if the output of these programs begins with a null character (or other non-printable character) that is 
confusing the "READ" argument? or if there is a timing problem that prevents "READ" from acquiring the first byte of returned data?

Incidentally,

> you have to do:
> SHELL "pushd /directory; find ./ | cpio -vco | gzip > /path/to/archive/file "

Acheives nothing. Leaving a space at the end of the string appears to have no effect whatsoever. The command works wether the white space 
is there or not, but doing:

SHELL "pushd /directory; find ./ | cpio -vco | gzip > /path/to/archive/file " WAIT FOR READ

only returns the output from "pushd" and not "cpio". Mind you I can't get the output from "cpio" at any time wether it is 
preceded with the "pushd" command or not. :-)


Ben