Os 3.2 development preview

[kolla]

No playing with cables alone is going to allow you to connect more than two devices. The internal IDE controllers can only handle one IDE channel without hardware to add logic for a second IDE channel, thus only two devices on stock IDE controller period.

The Aminet link you provided is for just this sort of hardware. It's not for any cable shenanigans.

Well, I managed to do it without making PCBs two decades ago, and it worked, the only components are two diods. Did you even look at the images in the archive?

[kolla]

@Thomas Richter
Could you share your thoughts on behaviour of shell regarding aliases, brackets and pipes?

For example, a simple alias Find

Code: [Select]

Alias MyFind "List DATA: all files p=*"[]*" lformat *"%p%n*""the user may think then, that this would work...

Code: [Select]

Find myfile | command
But this currently expands to

Code: [Select]

List DATA: all files p="myfile | command" lformat "%p%n" and hence does (mostly!) nothing.

I don't know of any way to "terminate" the argument list of an alias, so one can use pipes with aliases. Does it exists? Will it exist in the future?

At last (bug)...

Code: [Select]

makedir RAM:test?
List all RAM:tes#?
It's very annoying when standard OS tools don't handle characters that are valid in filenames.. I hope the new tab-completion is smarter with file names containing parantheses etc, escaping them properly.

[Thomas Richter]

Could you share your thoughts on behaviour of shell regarding aliases, brackets and pipes?

For example, a simple alias Find

Code: [Select]

Alias MyFind "List DATA: all files p=*"[]*" lformat *"%p%n*""the user may think then, that this would work...

Code: [Select]

Find myfile | command
But this currently expands to

Code: [Select]

List DATA: all files p="myfile | command" lformat "%p%n" and hence does (mostly!) nothing.

Right. "Alias" is quite a stupid buddy. It does blind substitution of its arguments, and it does not intend to understand what is on the command line. If you need smarter argument substitution, "execute" is your friend.

At last (bug)...

Code: [Select]

makedir RAM:test?
List all RAM:tes#?
It's very annoying when standard OS tools don't handle characters that are valid in filenames..

Sorry, I don't have an amiga here. What is the bug part? "makedir" creates a directory which has a question mark in its name. List itself does not do much with that. This is all handled by the dos.library pattern matcher (or arp pattern matcher).

I hope the new tab-completion is smarter with file names containing parantheses etc, escaping them properly.

The TAB expansion knows now the shell syntax, yes, including escaping of them for the arp pattern matcher. It also knows how to expand variables on the way, and the names of variables as well.

[kolla]

Could you share your thoughts on behaviour of shell regarding aliases, brackets and pipes?

For example, a simple alias Find

Code: [Select]

Alias MyFind "List DATA: all files p=*"[]*" lformat *"%p%n*""the user may think then, that this would work...

Code: [Select]

Find myfile | command
But this currently expands to

Code: [Select]

List DATA: all files p="myfile | command" lformat "%p%n" and hence does (mostly!) nothing.

Right. "Alias" is quite a stupid buddy. It does blind substitution of its arguments, and it does not intend to understand what is on the command line. If you need smarter argument substitution, "execute" is your friend.

I fail to see how "execute" can substitute "alias", or do you suggest writing a script for every alias that have output one would wish to send through a pipe?

At last (bug)...

Code: [Select]

makedir RAM:test?
List all RAM:tes#?
It's very annoying when standard OS tools don't handle characters that are valid in filenames..

Sorry, I don't have an amiga here.

Hm, I thought you always had vamos at hand...

What is the bug part? "makedir" creates a directory which has a question mark in its name. List itself does not do much with that. This is all handled by the dos.library pattern matcher (or arp pattern matcher).

What happens is that "List", with "ALL" flag, will list the matching directory over and over and over again, as if it is a new directory that is matching, till you press ctrl-c, when it will summarise a total of many,many directories...

I hope the new tab-completion is smarter with file names containing parantheses etc, escaping them properly.

The TAB expansion knows now the shell syntax, yes, including escaping of them for the arp pattern matcher. It also knows how to expand variables on the way, and the names of variables as well.

Good. And now I also know how ctrl-r works in Amiga console - that only took me two decades...

[Thomas Richter]

I fail to see how "execute" can substitute "alias", or do you suggest writing a script for every alias that have output one would wish to send through a pipe?

That would work, yes. Alias is really not a very robust construction concerning parsing and argument subsitution. Old legacy C code drilled up from older legacy C automatically generated from even older legacy BCPL code.

Hm, I thought you always had vamos at hand...

Not in Taipeh and our IT department "we only do windows on business laptops, go away with your silly linux". )-:

What happens is that "List", with "ALL" flag, will list the matching directory over and over and over again, as if it is a new directory that is matching, till you press ctrl-c, when it will summarise a total of many,many directories...

That is a strange one, thank you. But that looks more like a defect in the arp pattern matcher because list does not contribute much to directory scanning.

[kolla]

I fail to see how "execute" can substitute "alias", or do you suggest writing a script for every alias that have output one would wish to send through a pipe?

That would work, yes. Alias is really not a very robust construction concerning parsing and argument subsitution. Old legacy C code drilled up from older legacy C automatically generated from even older legacy BCPL code.

Well, all this is all very non-obvious, Alias is a shell internal, as are pipes and backticks etc, and this should be fixed somehow. I suppose one should look at how the shells of OS4, MorphOS and AROS behave in such cases.

Hm, I thought you always had vamos at hand...

Not in Taipeh and our IT department "we only do windows on business laptops, go away with your silly linux". )-:

Windows Subsystem for Linux for Enterprise isn't good enough?

What happens is that "List", with "ALL" flag, will list the matching directory over and over and over again, as if it is a new directory that is matching, till you press ctrl-c, when it will summarise a total of many,many directories...

That is a strange one, thank you. But that looks more like a defect in the arp pattern matcher because list does not contribute much to directory scanning.

Well, guess we can all have a peek in the sources and find out? FWIW, it does not happen with List v43.4 (03-Sep-00).

[Thomas Richter]

Well, all this is all very non-obvious, Alias is a shell internal, as are pipes and backticks etc, and this should be fixed somehow. I suppose one should look at how the shells of OS4, MorphOS and AROS behave in such cases.

Why? We are not doing OS4,Morphos or AROS here? Do the following under a 3.1 shell:

Code: [Select]

1.> alias ls list "[]"
1.> ls sys: >ram:t

What should happen? The shell uses a blind substitution, and places ">ram:t" into the backticks of the alias, thus you get a requester as list receives "sys: >ram:t" as argument. Should alias substitution stop at the >ram:t?

Then what about the following:

Code: [Select]

1.> alias ls list "[]"
1.> ls >ram:t sys:

what is now the argument to the alias? None? That is the consequence if parsing stops at the redirection.

Aliases are not shell functions or command replacements. They don't see redirections.

FWIW, it does not happen with List v43.4 (03-Sep-00).

It was a bug in "list" indeed.

[psxphill]

What should happen? The shell uses a blind substitution, and places ">ram:t" into the backticks of the alias, thus you get a requester as list receives "sys: >ram:t" as argument. Should alias substitution stop at the >ram:t?

I personally think that the example you gave should have the >ram:t filtered out from the alias substitution & then applied to the command. Although there should probably be a way of overriding that behavior (maybe would need to think carefully about if that is when you set the alias or when you call it).

Not being able to redirect the output of an alias makes them pretty useless as a feature.

[Thomas Richter]

Not being able to redirect the output of an alias makes them pretty useless as a feature.

Oh, you can redirect aliases. You just cannot place [] in double quotes and expect that the redirection makes it through. What [] does is that it grabs the rest of the line behind the alias and places it wherever the [] are. Thus

Code: [Select]

1.> alias ls list [] all
replaces

Code: [Select]

1.> ls ram: >t:out
by

Code: [Select]

1.> list ram: >t:out all
which works fine of course. However, if you enclose [] in double quotes, everything on the line is captured in double quotes, including the redirection. This may or may not be what you want, but this is how alias works.

Thus, in general, [] and double quotes are *probably* not what you want. Note well that if the argument to the alias is quoted, the quotes will remain intact after substitution of [] with the argument, so it makes little sense to put quotes there in first place. In that sense, the example given is probably flawed to begin with.

[kolla]

Note that I never mentioned simple redirections, I was talking about something *BRAND NEW* for AmigaShell in 3.1.4 - effin’ PIPES!

[Pgovotsos]

Not being able to redirect the output of an alias makes them pretty useless as a feature.

Oh, you can redirect aliases. You just cannot place [] in double quotes and expect that the redirection makes it through. What [] does is that it grabs the rest of the line behind the alias and places it wherever the [] are. Thus

Code: [Select]

1.> alias ls list [] all
replaces

Code: [Select]

1.> ls ram: >t:out
by

Code: [Select]

1.> list ram: >t:out all
which works fine of course. However, if you enclose [] in double quotes, everything on the line is captured in double quotes, including the redirection. This may or may not be what you want, but this is how alias works.

Thus, in general, [] and double quotes are *probably* not what you want. Note well that if the argument to the alias is quoted, the quotes will remain intact after substitution of [] with the argument, so it makes little sense to put quotes there in first place. In that sense, the example given is probably flawed to begin with.

Could you please name the character that you are talking about enclosing in double quotes? For some reason it's showing as a block - an unknown character - on my browser.

Thanks

[Thomas Richter]

Could you please name the character that you are talking about enclosing in double quotes? For some reason it's showing as a block - an unknown character - on my browser.

No, it does not. It is really an opening and closing square bracket.

[kolla]

lol

[Pgovotsos]

Could you please name the character that you are talking about enclosing in double quotes? For some reason it's showing as a block - an unknown character - on my browser.

No, it does not. It is really an opening and closing square bracket.

Dang, I had to zoom that all the way in to see that little gap between the brackets. My old eyes seriously saw it as a square

[Gulliver]

Could you please name the character that you are talking about enclosing in double quotes? For some reason it's showing as a block - an unknown character - on my browser.

No, it does not. It is really an opening and closing square bracket.

Dang, I had to zoom that all the way in to see that little gap between the brackets. My old eyes seriously saw it as a square

The other day, we were discussing how the default OS installation should be, and I was mentioning the fact that our userbase is not getting any younger and that we should probably need to use bigger fonts.