[Gambas-user] Process/Shell Bug

[Benoit Minisini]

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.

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