list | more broken (?)

[Raziel]

First of all...THANK YOU very much for the great update
It feels faster, even more stable and it's just awesome to be able to install it without a complete new install. KUDOS!

Now for a simple misbehaviour i found.

list | more should list the files, stop when the shell's window bottom is reached and show the rest or next page when the user presses a key...

with update 3 none of this happens, instead the shell window is blanked and somehow "frozen"...i can move it around, resize, put to background, get it back to front and such but i cannot close it for my life

It just stays there and probably waits for something

Anyone can reproduce that?
Is it a regression?
PIPE is in Devs:/DOSDrivers, but i assume there was a change in L:queue-handler which triggers this behaviour, no?

Thank you very much again
Oh...it worked in update 2

[abalaban]

@Raziel

'xxx | more' always behave a bit strangely (IMHO, or at least compared to how someone used to the Unix feature would expect it to work). In practise I found myself using more and more the 'recorder' command line and then a 'more' or 'EditPad' on the result.
In the meantime this might be of some to you

[Raziel]

@Raziel

'xxx | more' always behave a bit strangely (IMHO, or at least compared to how someone used to the Unix feature would expect it to work). In practise I found myself using more and more the 'recorder' command line and then a 'more' or 'EditPad' on the result.
In the meantime this might be of some to you

I need to try that recorder thingie

Normally on large texts i do a list xxx >ram:xxx.txt and then read it with all the time i have

...still, this command shouldn't lock up the shell, should it?

[abalaban]

I need to try that recorder thingie

Normally on large texts i do a list xxx >ram:xxx.txt and then read it with all the time i have

Advantage of using recorder is that it does not prevent the shell output contrary to a simple file redirection. So you know in real-time (or quasi) what is going on unlike with a redirection.

...still, this command shouldn't lock up the shell, should it?

Yes I agree

[Hypex]

I can confirm here. It blanks my shell. How strange.

[nbache]

...still, this command shouldn't lock up the shell, should it?

It doesn't. Press Ctrl-C and then q, and you will get your prompt back.

Still, weird behaviour. I'll try experimenting a bit more here.

Best regards,

Niels

[tonyw]

None of the Shell/con-handler/console group has changed since Update 2, so it must be something else causing it.

[xenic]

PIPE is in Devs:/DOSDrivers, but i assume there was a change in L:queue-handler which triggers this behaviour, no?

I don't think so. I just replaced the Update3 more command with the Update2 more command and that works. It looks like someone botched an update of the more command

[Raziel]

@nbache

ah, thank for that
I gotta really try to dig out my old amiga knowledge

@xenic

damn, the nearest solution
good catch, thanks...do you also know who is responsible for the more command?
...and ask him to fix it

Hihi, i like the update

[broadblues]

It seams to be a probablem with more and reading from a pipe as:

list >PIPE:mypipe
more <PIPE:mypipe

fails in a similar way, once you hit ctrl-c you et a warning that the file might be binary.