AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks

[kolla]

So the bug is there, “quick format” should be reappear as available option in the Format window of the second partition once formatting of first partition is done. Like you wrote earlier. Do you acknowledge that this is a bug, or do you write it off as “expected behavior”, even though it makes zero sense from a user’s point of view?

In general, I don’t have a hard time writing bug reports, but with you, and just you, it’s a damn fight every effin time.

[kolla]

If the other partition is invalid (i.e. has no volume name on it), then this is expected. This is, again, due to the rather simple logic by which Format checks whether quick formatting is possible or not. If there is no volume name, it assumes that quick format is not possible. This check is made when changing disks, and the disk change is triggered by the disk-inserted message of the first format finishing.

Why is Format doing this check _only_ when disks are changed, and not when Format is launched?
Should "uninitialized" be treated as a special case, a case where "quick format" should be made possible?
Why did this change from OS 3.1?

[kolla]

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.

Yes.
And I would argue that Workbench windows can show file sizes as "human readable", for example "2GB" in you case.

[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".

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

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


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

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

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

[kolla]

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

[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

[kolla]

Moving on, since the topic on "that other thread" is about date, setdate etc, I have some thoughts, hopefully by posting here I don't risk getting banned for airing some ideas...


First C:Date

C:Date is a confusing puppy, as it is used both print and set system time.

I find it rather annoying that C:Date *requires* different input, depending on locale settings...

It would be very useful if it ...

* had an LFORMAT option for printing custom date strings, which implies not changing the system time

Code: [Select]

C:Date LFORMAT "The year is %Y, the month is %M, and the date is %D, time is currently %T"
C:Date tomorrow LFORMAT "Tomorrow is %M %D, %Y"
* accept input in a universal non-localized formats (iso 8601):

Code: [Select]

C:Date 2019-12-14T08:19:47Z
C:Date 2019-12-14T06:17:47+02:00
C:Date 2019-12-24
* could use timestamp of resources like files, directories, filesystems as reference, instead of system time, also neat for _setting_ the system time from a reference file or filesystem:

Code: [Select]

C:Date FROM S:Startup-Sequence LFORMAT "File is from %T at %D/%M, %Y"
C:Date FROM DH0:


[kolla]

I find it rather annoying that C:Date *requires* different input, depending on locale settings...

It requires as input the same format it prints as output.

It means that one cannot use the same input on two systems with different locale, as the TLA for months are different in different languages - it would be convenient if it at least also supported just plain English input.

Ironically and adding to confusion, error messages are _not_ localised, but all plain english.

Code: [Select]

4.Kladd:> date
Lørdag 14-Des-19 10:40:13
4.Kladd:> date yesterday
***Bad args
- use DD-MMM-YY or <dayname> or yesterday etc. to set date
      HH:MM:SS OR HH:MM to set time
4.Kladd:> date "i går"
4.Kladd:> date
Fredag 13-Des-19 10:41:07
4.Kladd:>

(What the use case is for jumping system-time back and forth day by day, I have no idea.. perhaps you know?)

It would be very useful if ...

* had an LFORMAT option for printing custom date strings, which implies not changing the system time

Code: [Select]

C:Date LFORMAT "The year is %Y, the month is %M, and the date is %D, time is currently %T"
C:Date tomorrow LFORMAT "Tomorrow is %M %D, %Y"

What is the use case for that? That is, what is the situation you run into trouble with the current way how "date" looks like?

Trouble? I just gave two example - it is *useful* for presenting time/date information in a way that is independent of locales - it looks funny when dates are presented in norwegian in a script that otherwise prints out english (and it doesn't help that the Norwegian locales are flawed as well).

Note well that we can certainly add something like Lformat for "date" in principle, but the output would still be locale dependent because the strings into which these formatting options expand into depend on the locale.

That is fine.

Ideally, IMO, C:Date (and the other CLI tools) should primarily use $LANGUAGE and secondly use locale settings - it should be possible to easily override system wide locale setting with a shell-local/script-local variable. Yes, I know that $LANGUAGE is a legacy BCPL/TRIPOS variable. Any program that is not localised in itself, should never require localised input - the C:Date error messages are in English, for me they should have been in Norwegian - I only found out that I must use "I går" and "I morgen" (yes, two words, with quotes around) by chance.

* could use timestamp of resources like files, directories, filesystems as reference, instead of system time, also neat for _setting_ the system time from a reference file or filesystem:

Code: [Select]

C:Date FROM S:Startup-Sequence LFORMAT "File is from %T at %D/%M, %Y"
C:Date FROM DH0:


Again, what is the use case?

Sheesh! Again - to present time and date information in a contextual meaningful way from scripts.

I understand that at some point you want to carry over a date from one file to another. SetDate FROM can do that for you. Why date?

Why do you want to carry over date from one file to another? What is the use case for that?

In my above example, the idea is that "Date FROM DH0:" sets system time from the timestamp of DH0: - useful when DH0: is not initial boot device, for example when booting from RAD:

And can you explain what "Setdate DH0:" actually does?

[kolla]

Moving on, on the topic of system time...

Default Amiga system time is default boot system time is 01-Jan-1978 00:00:00, if I recall correctly.

At boot, the Amiga will look for a an RTC (real time clock, typically battery backed), from what I understand this is what battclock.resource does.

If RTC is found, system time is set from that.

If RTC is _not_ fond, it will move on to look for timestamp on the filesystem of the boot device - it is unclear for me what timestamp is actually used, since "the experts" seems to disagree on what is used an what it is supposed to use, and it doesn't help that different filesystems treat these timestamp fields differently. What it looks like though, is that with FFS, the so called "Creation time" is used, and there are no tools in the OS that can alter this timestamp, other than SYS:System/Format. So this means that whenever you boot a system, system time will be the same as when the system partition was formatted, and all changes to files will be marked as done in the "future" on every boot. Not so satisfying.

There are work-arounds for this.

For example I used to have a small script running in the background that just use SetDate to update a SYS:.timestamp every 60 seconds, and on boot a script lists this timestamp file with LFORMAT that matches the input that C:Date accepts (this is so early that locales are not allowed to screw things up yet) and system time is hence set to the last time the sys:.timestamp file was updated. Of course it would help A LOT if C:Date could just have an option FROM, so all locale issues were forever gone for this _use case_. But writing to a disk filesystem every minute or so can be "dangerous", so a more safe option is to instead write to a warm-boot resident area in RAM. One can do this just by using OS tools, simply by making the smallest RAD disk possible, make sure it has lower bootpri than the system disk, and use a timestamp file there, and only write to a disk filesystem when turning off the machine entirely.

But this can be done better. On Aminet there is a tool TimeKeeper that does something clever - it reserves a small address space in RAM, makes it warm-boot resident, and then goes in the background as a "daemon" and keeps on writing the system timestamp to this address space every few seconds. On boot, it will then look for this address space and set system time accordingly. A boot typically takes a few seconds, depending on setup, so it also accepts an offset option, so one can add these seconds. If no timestamp is found, or it is scrambled, it also supports running a command line, which then can be used to set the system time from a different source, for example from timestamp file on a filesystem.

But all this are work-arounds, I very much think that AmigaOS 3 should by much better in dealing with system time on systems lacking RTC, and I certainly have ideas

[kolla]

Yes, but when is this a problem? So, what is a script where you depend on date to act in a non-interactive way?

Any system that lacks a functioning RTC, which I believe is vast majority of Amiga systems.

[kolla]

Why is the output of a script running on a German system non-meaningful if it appears in German?

Context.

Just because I have Norwegian locale (which Hyperion says I MUST use to stay license compliant, despite the cringing quality of the locales) does not mean I can not be in non-Norwegian contexts. We live in a reality where one cannot expect everything to be localised correctly, for many of us the correct locale does not even exist, and most of us are not mono-lingual. In SYS:Prefs/Locale can set up a prioritised list of languages, and this can lead to programs/scripts having mixed language output, which can be both entertaining and confusing.