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

[audiossis]

On Friday 06 July 2007 22:15:41 you wrote:
> On Friday 06 July 2007 22:02:31 gambas-user-request at lists.sourceforge.net wrote:
> > Message: 1
> > Date: Fri, 6 Jul 2007 10:02:29 +0200
> > From: Benoit Minisini <gambas at ...1...>
> > Subject: Re: [Gambas-user] More Problems with SHELL (possible BUG).
> > To: mailing list for gambas users <gambas-user at lists.sourceforge.net>
> > Message-ID: <200707061002.29711.gambas at ...1...>
> > Content-Type: text/plain;  charset="iso-8859-1"
> > 
> > On vendredi 06 juillet 2007, audiossis wrote:
> > > 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
> > >
> > 
> > You must do:
> > 
> > SHELL "pushd /directory; find ./ | cpio -vco | gzip > /path/to/archive/file 
> > 2>&1" WAIT FOR READ
> > 
> > If you don't add "2>&1" to each shell command, so that the standard error 
> > output is redirected to the standard output, then you won't get the standard 
> > error output data in the 'Read' event handler.
> > 
> > Or you can use the 'Error' event to catch the standard error output directly.
> > 
> > Regards,
> > 
> > -- 
> > Benoit Minisini
> 
> That's very interesting. It seems that there is definitely more than one way to skin this cat!
> 
> Ron just showed me different method which also works. I won't post it here as I've already replied to his message, but thankyou all the same.
> I'll try what you have suggested to see which way appears to work the best and I'll keep you posted!!
> 
> Thanks again!
> 
> Ben



OK, so in the end point this is definitely NOT a bug. Taking something from each suggestion that was made, I think I have come up with the most 
efficient solution to my problem.

The code below is an abridged version (heavily abridged) of what I am actually using but it clearly demonstrates the principals we've discussed 
and it works.


'Declare global variables however you choose to do so
PUBLIC hStream AS Stream
PUBLIC sOut AS String


PUBLIC SUB Button1_Click()

SHELL "mkdir -v /working/directory 2>&1" WAIT FOR READ
SHELL "cp -var /some/file1 /working/directory" WAIT FOR READ
SHELL "cp -var /some/file2 /working/directory" WAIT FOR READ
SHELL "(pushd /working/directory; find ./ | cpio -vco | gzip -v > /path/to/archive/file) 2>&1" WAIT FOR READ
SHELL "rm -vr /working/directory" WAIT FOR READ

CLOSE #hStream

END


PUBLIC SUB Process_Read()

IF EXIST "/path/to/log/file" THEN
	hStream = OPEN "/path/to/log/file" FOR APPEND
ELSE
	hStream = OPEN "/path/to/log/file" FOR CREATE
ENDIF

READ #LAST, sOut, 1
IF sOUT = "\n" then
	PRINT #hStream, "\n" & Now & " ";
ELSE
	PRINT #hStream, sOUT;
ENDIF

END




In addition to performing the shell functions it produces a log file of it's activities that looks something like this:


07/06/2007 22:48:58.07 mkdir: created directory `/working/directory'
07/06/2007 22:48:58.112 `/some/file1' -> `/working/directory/file1'
07/06/2007 22:48:58.233 `/some/file2' -> `/working/directory/file2'
07/06/2007 22:48:58.235 /current/directory /working/directory
07/06/2007 22:48:58.237 ./
07/06/2007 22:48:58.238 ./file1
07/06/2007 22:48:58.239 ./file2
07/06/2007 22:48:58.241 20 blocks
07/06/2007 22:48:58.242 62.5%
07/06/2007 22:48:58.245 removed directory: `/working/directory'
07/06/2007 22:48:58.247


Notes: I chose to grab only 1 byte from the "#LAST" stream at a time because the returning data varied in length and this was the simplest way I
could find of preventing text corruption in the log file, while maintaining the date/time stamp at the beginning of each new line.
It probably sacrifices efficiency but at least the log file is readable.

Many thanks to Stefano, Ron and Benoit for their invaluable advice and guidance.
Keep up the good work! Talk to you soon....... :)

Ben