Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

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

0 Members and 1 Guest are viewing this topic.

guest11527

  • Guest
Your answer makes little sense to me - I have exactly zero scripts going on here, and certainly not recursive scripts.
The thing you pipe into execute is what if not a script?


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.
At least I do not see this in the current version of shell and execute, even more so as the pipe construction is part of the startup-sequence that will be shipped.


* 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
Maybe so, but there are more applications for piping commands into execute than to pipe script names into execute. In particular, for mounting devices and monitor drivers, this is a very handy construction.

You may also recognize that I made "LFORMAT" aware of the shell escaping mechanisms, so that problem is also gone. "RequestFile" already did that right, but LFORMAT did not. One bug at a time....

Offline my_pc_is_amiga

This is regards to copy in 3.1.4.1.  Attaching 2 screenshots:

1) On Workbench, I copy a directory called "INTELLIFONT" and there is some issue with one of the files and so I get an error requester.  The error message is somewhat confusing as it mentions error copying "INTELLIFONT" but error is really from the file DESIR***** --> see picture for actual name.  Would be nice to have the requester say the filename with issue and to let user know that only the single file is not going to be copied.

2) I also tried to copy same file in shell and get similar message that object cannot be found.  For this name, what is wrong or why can't it be copied?

guest11527

  • Guest
2) I also tried to copy same file in shell and get similar message that object cannot be found.  For this name, what is wrong or why can't it be copied?
It cannot be copied because you specified the file name incorrectly. ~ is a wild card for pattern matching. If it is meant to be a literal, you need to place a ' upfront it. Actually, from how it looks, this seems to be a mangled file name from a FAT directory. Are you copying from CrossDos? It should resolve such strange file names and provide a full FAT file name.
 

Offline my_pc_is_amiga

Yes, I'm using CrossDos.  The source file is coming from a USB stick but I have poseiden setup to use crossdos.

2) I also tried to copy same file in shell and get similar message that object cannot be found.  For this name, what is wrong or why can't it be copied?
It cannot be copied because you specified the file name incorrectly. ~ is a wild card for pattern matching. If it is meant to be a literal, you need to place a ' upfront it. Actually, from how it looks, this seems to be a mangled file name from a FAT directory. Are you copying from CrossDos? It should resolve such strange file names and provide a full FAT file name.
 

guest11527

  • Guest
Yes, I'm using CrossDos.  The source file is coming from a USB stick but I have poseiden setup to use crossdos.
Then either something is mangled with the setup, the stick or crossdos. Is it possible to share the image so I can have  a look why Crossdos doesn't resolve the long file name? Which version of crossdos?
 

Offline my_pc_is_amiga

Yes, I'm using CrossDos.  The source file is coming from a USB stick but I have poseiden setup to use crossdos.
Then either something is mangled with the setup, the stick or crossdos. Is it possible to share the image so I can have  a look why Crossdos doesn't resolve the long file name? Which version of crossdos?

Attaching the file in *.zip from windows.  Need to unzip from windows so the name stays the same.  If I do it on the Amiga, unarc from 3.9 changes the name.
 

guest11527

  • Guest
Attaching the file in *.zip from windows.  Need to unzip from windows so the name stays the same.  If I do it on the Amiga, unarc from 3.9 changes the name.
No, not the font file. I mean an image of the stick, sector wise. I do not know how to get that with windows, but from Linux, it is a straight "cp" from the /dev file, i.e. "cp /dev/sdd /tmp/out.img", assuming that /dev/sdd is your usb stick.
 

Offline my_pc_is_amiga

It actually came from this ISO image:

https://archive.org/details/cdrom-freshfonts-2

Attaching the file in *.zip from windows.  Need to unzip from windows so the name stays the same.  If I do it on the Amiga, unarc from 3.9 changes the name.
No, not the font file. I mean an image of the stick, sector wise. I do not know how to get that with windows, but from Linux, it is a straight "cp" from the /dev file, i.e. "cp /dev/sdd /tmp/out.img", assuming that /dev/sdd is your usb stick.
 

guest11527

  • Guest
It actually came from this ISO image:
https://archive.org/details/cdrom-freshfonts-2
Thanks, but how did it get on your stick? With a PC on Windows? Was the font name already garbled on the ISO image?
 

Offline my_pc_is_amiga

Yes, it was with Windows 10 (Iso image gets mounted by Windows).  I'm attaching a screenshot from Windwos of the names that show up.   From their I copied it to a USB drive.
 

Offline my_pc_is_amiga

The filename in windows looks like character 233 (Ө) for MS-DOS (PC-8), code page 437:
https://en.wikipedia.org/wiki/Code_page_437

and for 233 decimal in Latin-1 comes out to be é

So that I think is making sense that é shows up on the Amiga but still don't understand why the non-8.3 filename (long filename) does not show up. 

I forgot to mention that this is crossdosfilesystem 45.36.
 

Offline 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:
« Last Edit: December 14, 2019, 09:33:45 AM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM460 and Mac minis with MorphOS
 

guest11527

  • Guest
So that I think is making sense that é shows up on the Amiga but still don't understand why the non-8.3 filename (long filename) does not show up. 
It cannot, because the character is not in the codeset. The "funny character" is a greek theta ("th"). It is part of the UTF-16 character set Windows uses, and which is also used to encode characters in the long file name. However, the theta is not part of ISO-Latin1, so there is no valid transcription of the file name to the charset AmigaOs uses. For this purpose, CrossDos falls back to the 8.3 filename.

As a reminder: UTF-16 encodes characters in 16-bit codepoints (well, ignoring the extended code pages for a while). The theta is beyond the first 256 byte page, where the first 256 codes are identical to ISO-Latin-1 (the codeset used by the Amiga).
 

guest11527

  • Guest
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 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?

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.


* 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? 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?
 

Offline 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?)


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

Quote

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.

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

Quote
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?
« Last Edit: December 14, 2019, 10:02:42 AM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM460 and Mac minis with MorphOS