[Gambas-user] Process/Shell Bug

Timothy Marshal-Nichols timothy.marshal-nichols at ...247...
Mon Aug 28 14:13:14 CEST 2006


> -----Original Message-----
> From: gambas-user-bounces at lists.sourceforge.net
> [mailto:gambas-user-bounces at lists.sourceforge.net]On Behalf Of Benoit
> Minisini
> Sent: Monday, 28 August 2006 10:51
> To: mailing list for gambas users
> Subject: Re: [Gambas-user] Process/Shell Bug
>
>
> On Monday 28 August 2006 09:42, Timothy Marshal-Nichols wrote:
> > Hello Benoit,
> >
> > Just thought I should add this to your TO-DO list. I have been
> meaning to
> > report this bug for some time. It was Stefano's comments that
> suggested you
> > might be looking at the SHELL and EXEC functions. So now might be a good
> > time to look at this bug.
> >
> > To see the bug open the Gambas Console in the example projects
> and run it.
> > (The bug in not in the example project. I found the bug in my own
> > projects.) Type this command in the Gambas Console TextBox:
> >
> > 	ls -l $HOME | cat -n
> >
> > In this command we use 'cat -n' just to number the lines. (This
> will make
> > it easier to see the bug later.) You should see nothing wrong. Now try a
> > command that returns a lot more data. For example:
> >
> > 	ls -l /proc | cat -n
> > 	lsof | cat -n
> > 	ps aux | cat -n
> > 	find $HOME -type d | cat -n
> >
> > After about 30 to 70 lines some lines have been split across two lines.
> > This depends on the length of a lines returned. The problem
> appears to be
> > LINE INPUT #LAST splitting a line in two where it should have
> returned one.
> >
> > Oddly sometimes after about 500 (approx) lines the split lines
> do not occur
> > anymore. The bug is when a lot of lines are returned. When only a small
> > amount of data is returned there is not problem.
> >
> > The 'cat -n' in the above commands is just to make it easier to see the
> > bug.
> >
> > I have just been looking at Gambas version 1.9.40 (on SUSE
> 10.1) and 1.0.16
> > (on Fedora 4). Sorry but this bug is in the stable version as well.
> >
> > Thanks
> >
> > 8-{)} Timothy Marshal-Nichols
> > <mailto: timothy.marshal-nichols at ...247...>
> >
>
> Just a remark to beginning: but why each time you send a mail to the
> mailing-list, your mail is always attached to a non-related
> thread? Is it you
> fault, or is there a bug in the mailing-list or in KMail?
>
> Well, now let's see your problem.
>
> Actually this is not a Gambas bug, but a buggy example!
>
> You should never use LINE INPUT to read the process output, but
> READ instead,
> because if there is no newline character in the pipe that receives the
> process output, then LINE INPUT will assume that the end of the
> pipe is like
> a new line.


Then why have this as an example? Also the help for both SHELL and EXEC show
using LINE INPUT to read the process. This is just misleading.

>
> As a pipe buffer is 4K, this does not occur if the process prints
> less than 4K
> to its standard output.
>
> To solve this problem, instead of doing:
>
> PUBLIC SUB Process_Read()
>
>   DIM sStr AS String
>
>   LINE INPUT #LAST, sStr
>
>   ...
>
> END
>
> You must do:
>
> PUBLIC SUB Process_Read()
>
>   DIM sStr AS String
>
>   ' Read up to 256 characters. Yo can put whatever value you want,
>   ' but I suggest less than 4K, the pipe buffer size, as you will
>   ' never get more data in one shot.
>   READ #LAST, sStr, -256
>
> END
>
> Regards,
>
> --
> Benoit Minisini
>
>

Thanks

8-{)} Timothy Marshal-Nichols
<mailto: timothy.marshal-nichols at ...247...>






More information about the User mailing list