Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A600 Memory

AuthorTopic: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks  (Read 7978 times)

0 Members and 1 Guest are viewing this topic.

Offline Thomas Richter

I have a rather large file: 2,287,031,227 bytes.  The size shows up correctly in the Information window and shell.  But in Workbench view by size, it shows up as ,007,936,069.
Apparently, another signed/unsigned mixup. I fixed it.
 
The following users thanked this post: my_pc_is_amiga

Offline my_pc_is_amiga

Great -- another bug squashed!

I have a rather large file: 2,287,031,227 bytes.  The size shows up correctly in the Information window and shell.  But in Workbench view by size, it shows up as ,007,936,069.
Apparently, another signed/unsigned mixup. I fixed it.

Offline my_pc_is_amiga

Took me awhile to find some hard drive to play with.  I see it happening in Format 40.2 (3.1)  and 3.1.4 (46.14) but in 3.9 (Format 44.19) I do not see this behavior. Quick format does not get ghosted out in the second partition in 44.19 at the completion of the first partition's quick format.

I ran each of the "Format" versions in a 3.9 booting env. -- so it is clearly in the Format code.

And as Thomas has pointed out it does not happen if partitions are non-invalid (i.e. already have valid volume names).


Partition up a disk with HDToolBox - two partitions.

Reboot.

They both show up as "unititialized".

Select both.

Select "Format" from the icon menu.

Notice how both Format windows, one for each partition, has "Quick format" as options.

Select "Quick format" on one of them.

Answer all confirmation requesters so the partition is formatted.

Let it finish - it is quick.

The partition is now formatted, volume icon shows up on Workbench.

Notice how _THE OTHER_ Format window, for _THE OTHER_ partition now has "Quick format" grayed out - EVEN AFTER FIRST FORMATTING IS FINISHED.
 
The following users thanked this post: Tygre

Offline my_pc_is_amiga

Was seeing if any clues in the "Format" release notes in the NDK 3.9 and found the following.  Though not sure if this means much since there is no way to look at this code to figure out what is being said below.

Code: [Select]
-- OS 3.5 release ---

Format 44.14 (7.12.99)

- rework

- Starting format with more than one WB parameter now correctly closes all
  windows. This is a ugly hack: the main window is closed and reopened
between
  formatting two devices. Too much work to make it nicer (Did you recognize
  that selecting two icons from WB and using menu Icon/Format Disk starts
  Format two times?)

- Removed broken handling of inserting/removing disk while main window is
open.
 
The following users thanked this post: Tygre

Offline kolla

More annoyances with Workbench (and shell)... copying icons by dropping source icon onto the target icon in "wbinfo" window - for whatever reason (bug? feature?) this requires that the source is not just a dot.info file, but an actual file (or drawer, or volume...). If you try to just drag a source icon with no associated file over to the target icon in the wbinfo window, exactly nothing will happen. As most icon packages come with just .info files, this is really annoying. Work-around is to create for example empty files for each .info file that lacks an associated file. This can be done fairly easily with a "one-liner" in OS 3.1.4.1 ...

Code: [Select]
List path/to/iconpack all files p="#?.info" lformat "If NOT EXISTS *"%p%m*"*N  Echo NOLINE TO *"%p%m*"*NEndIf" | C:Execute

Note that if Execute is made resident, it will not work to write just "| Execute" - bug that hopefully is squashed in 3.2.

Also note, the shell will barf on any files that have * (asterisk) in the filename, because... asterisks in filenames makes the shell barf in all kinds of funny ways, due to this sign having multiple meanings for the shell, depending on context ("this console", escape sign, substitute for #? if enabled)

And lastly, I have observed inconsistent and timewise weird behaviour with "set echo on" when using pipes and execute... as the whole Shell is up in the air at this point and these may or may not be known issues, I will not bother to conduct detailed test - just a heads up. "the team" (shrug) should thoroughly test behaviour of the shell with "set echo on" and similar "special cases".
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Thomas Richter

More annoyances with Workbench (and shell)... copying icons by dropping source icon onto the target icon in "wbinfo" window - for whatever reason (bug? feature?) this requires that the source is not just a dot.info file, but an actual file (or drawer, or volume...). If you try to just drag a source icon with no associated file over to the target icon in the wbinfo window, exactly nothing will happen. As most icon packages come with just .info files, this is really annoying. Work-around is to create for example empty files for each .info file that lacks an associated file. This can be done fairly easily with a "one-liner" in OS 3.1.4.1 ...
I cannot confirm this. If I open the info window, and drag a file with only a .info and no file in it, I get the new icon all fine. The only particular combination in which nothing happens is if you open a drawer which is "list by names", and "show all files", and you drag a file without an icon into the info window. Then nothing happens. Which is plausible as there is no icon to begin with.

Code: [Select]
List path/to/iconpack all files p="#?.info" lformat "If NOT EXISTS *"%p%m*"*N  Echo NOLINE TO *"%p%m*"*NEndIf" | C:Execute

Note that if Execute is made resident, it will not work to write just "| Execute" - bug that hopefully is squashed in 3.2.
I can neither confirm that.

Also note, the shell will barf on any files that have * (asterisk) in the filename, because... asterisks in filenames makes the shell barf in all kinds of funny ways, due to this sign having multiple meanings for the shell, depending on context ("this console", escape sign, substitute for #? if enabled)
This is at this level unfortunate, though a problem of list and lformat and not of the shell. The problem is that List is not smart enough to understand that the %p%m is within quotes, so it does not perform substitution of asterisks. It should replace a single asterisk by two of them to be compliant to the shell syntax, but apparently CBM forgot. An asterisk within double quotes is an escape character. I wonder how this could possibly be fixed without a lot of additional testing within List, but I'll see.

And lastly, I have observed inconsistent and timewise weird behaviour with "set echo on" when using pipes and execute... as the whole Shell is up in the air at this point and these may or may not be known issues, I will not bother to conduct detailed test - just a heads up. "the team" (shrug) should thoroughly test behaviour of the shell with "set echo on" and similar "special cases".
At least not an issue I have on the list. Details?

Offline kolla

I cannot confirm this. If I open the info window, and drag a file with only a .info and no file in it, I get the new icon all fine. The only particular combination in which nothing happens is if you open a drawer which is "list by names", and "show all files", and you drag a file without an icon into the info window. Then nothing happens. Which is plausible as there is no icon to begin with.

Mea culpa - I was confusing myself with RAWBInfo - default WBInfo does indeed work correctly.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline kolla

Note that if Execute is made resident, it will not work to write just "| Execute" - bug that hopefully is squashed in 3.2.
I can neither confirm that.

Code: [Select]
4.Ram Disk:> which execute
Workbench:C/Execute
4.Ram Disk:> list Workbench:C/Execute
Directory "Workbench:C" on Monday 02-Dec-19
Execute                     6124 h-p-rwed 29-Jun-19 20:52:53
1 file - 13 blocks used
4.Ram Disk:> dir
     Clipboards (dir)
     T (dir)
  Disk.info <sl>
4.Ram Disk:> echo dir | execute
     Clipboards (dir)
     T (dir)
  Disk.info <sl>
4.Ram Disk:> which execute
RES execute
4.Ram Disk:> echo dir | execute
     Clipboards (dir)
     T (dir)
  Disk.info <sl>
4.Ram Disk:> newcli *
New Shell process 3
4.Ram Disk:> 3.Ram Disk:> echo dir | execute
required argument missing
3.Ram Disk:> which execute
RES execute
3.Ram Disk:> endcli
Process 3 ending
4.Ram Disk:> which execute
RES execute
4.Ram Disk:> echo dir | execute
     Clipboards (dir)
     T (dir)
  Disk.info <sl>
4.Ram Disk:>
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline kolla

Notice the "required argument missing" error message - it does not happen in the same CLI processes from where Execute at some point has been made resident.

A work-around is to have "Resident C:Execute" in S:Shell-Startup (and every damn script calling it).
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline kolla

The problem is that List is not smart enough to understand that the %p%m is within quotes, so it does not perform substitution of asterisks. It should replace a single asterisk by two of them to be compliant to the shell syntax, but apparently CBM forgot.

CBM, and everyone else up to List 45.9 from March 22. 2018, apparently.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Thomas Richter

A work-around is to have "Resident C:Execute" in S:Shell-Startup (and every damn script calling it).
You *must* make Execute resident, but you better do so in the startup-sequence. Without that, recursive script execution won't work right. This is essential. In 3.2 and on, execute is resident anyhow.
 

Offline kolla

A work-around is to have "Resident C:Execute" in S:Shell-Startup (and every damn script calling it).
You *must* make Execute resident, but you better do so in the startup-sequence. Without that, recursive script execution won't work right. This is essential. In 3.2 and on, execute is resident anyhow.

How do you think I discovered this problem?

I do have Execute made resident in Startup-Sequence, but that is not "good enough" - when I open a shell and do (for example) "echo dir | execute" it just says "required argument missing", if I do "echo dir | C:Execute" it works - it also works if I first do "Resident C:Execute" again in that CLI (despite Execute already being resident).
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline kolla

It should really be enough to just do "Protect C:Execute +hp".
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Thomas Richter

I do have Execute made resident in Startup-Sequence, but that is not "good enough" - when I open a shell and do (for example) "echo dir | execute" it just says "required argument missing", if I do "echo dir | C:Execute" it works - it also works if I first do "Resident C:Execute" again in that CLI (despite Execute already being resident).
Once again: If you call Execute directly, you do not have recursive shell scripts. In this particular case, it does not matter, but it matters in general.
 

Offline kolla

I do have Execute made resident in Startup-Sequence, but that is not "good enough" - when I open a shell and do (for example) "echo dir | execute" it just says "required argument missing", if I do "echo dir | C:Execute" it works - it also works if I first do "Resident C:Execute" again in that CLI (despite Execute already being resident).
Once again: If you call Execute directly, you do not have recursive shell scripts. In this particular case, it does not matter, but it matters in general.

Your answer makes little sense to me - I have exactly zero scripts going on here, and certainly not recursive scripts. I am passing on output from one command over to another via the pipe - and sometimes it works as I have been told is expected, other times it does not. Unless by "script" you mean whatever is created on the left side of the pipe, and recursiveness coming from using scripts from an interactive shell.

If Execute is not at all resident, everything works as expected(*), but if Execute is resident, it does not work, in general. The exception is if Execute is explicitly made resident from the CLI where the piping happening.

* I find it counter-intuitive that Executive will take commands from stdin "/bin/sh style", I would find it more "natural" if it accepted a list of scripts...
Code: [Select]
type s:user-startup | execute vs
Code: [Select]
echo s:user-startup | execute
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC