Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Hollywood MAL AMIStore App Store A600 Memory

AuthorTopic: Os 3.2 development preview  (Read 31736 times)

0 Members and 5 Guests are viewing this topic.

Online kolla

Re: Os 3.2 development preview
« Reply #135 on: September 21, 2019, 05:32:43 PM »
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?
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Online kolla

Re: Os 3.2 development preview
« Reply #136 on: September 22, 2019, 10:37:11 AM »
@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.
« Last Edit: September 22, 2019, 12:32:22 PM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Thomas Richter

Re: Os 3.2 development preview
« Reply #137 on: September 22, 2019, 01:10:17 PM »
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.

Online kolla

Re: Os 3.2 development preview
« Reply #138 on: September 23, 2019, 02:07:51 PM »
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?

Quote
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...

Quote
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...

Quote
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... :)
« Last Edit: September 23, 2019, 02:09:30 PM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Thomas Richter

Re: Os 3.2 development preview
« Reply #139 on: September 23, 2019, 04:05:59 PM »
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.


Online kolla

Re: Os 3.2 development preview
« Reply #140 on: September 24, 2019, 11:51:48 AM »
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.
Quote
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? :)
Quote
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).
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Thomas Richter

Re: Os 3.2 development preview
« Reply #141 on: September 27, 2019, 01:20:08 PM »
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.

Offline psxphill

Re: Os 3.2 development preview
« Reply #142 on: September 28, 2019, 10:47:18 AM »
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.
 

Offline Thomas Richter

Re: Os 3.2 development preview
« Reply #143 on: September 28, 2019, 12:09:50 PM »
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.

Online kolla

Re: Os 3.2 development preview
« Reply #144 on: September 28, 2019, 12:41:11 PM »
Note that I never mentioned simple redirections, I was talking about something *BRAND NEW* for AmigaShell in 3.1.4 - effin’ PIPES!
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Pgovotsos

Re: Os 3.2 development preview
« Reply #145 on: September 28, 2019, 04:01:22 PM »
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
 

Offline Thomas Richter

Re: Os 3.2 development preview
« Reply #146 on: September 28, 2019, 05:17:03 PM »

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.

Online kolla

Re: Os 3.2 development preview
« Reply #147 on: September 28, 2019, 06:55:58 PM »
lol
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Pgovotsos

Re: Os 3.2 development preview
« Reply #148 on: September 29, 2019, 06:26:23 AM »

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 :)
 

Offline Gulliver

Re: Os 3.2 development preview
« Reply #149 on: September 29, 2019, 12:01:06 PM »

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.   :)