Home  News  Recent  Forums  Search  Contact


   Register here

 Main menu
   View images
   BBCode test
   Statement of intent
   Terms Of Service
   IRC Channel
   List Content

 In cooperation with

  Amiga Flame
  Amiga Spirit
  View comments
      AmigaOS 4  
saimoRename bug20110312 16:56

sorry if there's a better thread for reporting AOS4 bugs, but I couldn't spot one (I only had a quick look as I'm a hurry...).

I just discovered a bug in the Rename command: it returns 0 (OK) when the target filename already exists (and the output is scrambled). F.ex., given the files "a" and "b", doing

> Rename a b


RENAME: Can't rename "a" as "b" because
RENAME: object already exists

and returns a code of 0.
Navigate: 1-15 
nbacheRe: Rename bug20110312 23:33  #2836

I agree with you about the return code. But why do you say the output is scrambled? What is wrong with it in your opinion?

Best regards,

saimoRe: Rename bug20110313 13:28  #2841

I'd say the output should look like this:

RENAME: Can't rename "a" as "b" because object already exists.
centaurzRe: Rename bug20110313 14:26  #2842

Err... this is just the usual way DOS commands have been reporting errors for ages. The header is repeated on each line.
saimoRe: Rename bug20110313 15:31  #2843

I must have not paid attention to that. My bad.
rigoRe: Rename bug20110313 16:39  #2844

Apart from requiring some rework of the code where this error is generated, it would also require changes to the localisation strings, which could have far reaching effects on other components, as it uses a shared catalog.

In short, it's unlikely the output will be changed, but I've fixed the error code returned for Rename 53.1.

Thanks for the report.

saimoRe: Rename bug20110313 20:56  #2851

Thanks for the quick fix :)
The weird output isn't much of an issue and I perfectly understand the catalog side issues, so I agree with leaving it the way it is.
nbacheRe: Rename bug20110313 23:05  #2853


Err... this is just the usual way DOS commands have been reporting errors for ages. The header is repeated on each line.

Indeed. As a matter of fact, this example is rather decent, compared to what is often seen with e.g. third party programs which are not localized, or not translated to your chosen language. Then you see the first line in English and the second line, with the DOS error, in your own language.

As centaurz says - it's just the way it is.

Best regards,

TrevRe: Rename bug20110314 01:40  #2857

I think your example is more readable. If the cataloged insertion strings are truly separate from the implementation, then the placement of strings on the same line should be just as easy to implement as the placement of strings on separate lines. Given the strings:

LOREM: Pellentesque habitant "%2" morbi "%1."
IPSUM: Et netus et malesuada.


FELIS: Pellentesque habitant "tristique" morbi "senectus." Et netus et malesuada.

The positioning of the sentences is an issue regardless, as IPSUM might logically precede LOREM in some languages. In that sense, Rigo's deference to complexity--it's spaghetti!--applies. I definitely don't accept the apathetic response. If this were a larger commercial endeavor (or an open source one), we might have linguists and experts in localization to help with this sort of thing. Microsoft, the maybe-not-so-evil-as-Apple empire, has a lot of great documentation on localization that's applicable to any design.
saimoRe: Rename bug20110314 10:23  #2858

Indeed. As a matter of fact, this example is rather decent, compared to what is often seen with e.g. third party programs which are not localized, or not translated to your chosen language. Then you see the first line in English and the second line, with the DOS error, in your own language.

As centaurz says - it's just the way it is.

As you can see from my answers above, to me the printout wasn't much of an issue and I do understand that fixing it might require some work that, given the situation, would be better to dedicate to other parts of the OS.

It wasn't my intention to discuss the issue further, but given that the discussion continues, I'll add a few thoughts...

1. The splitting on a single sentence over two lines is bad - that's different from having two separate messages.

2. "it's just the way it is" isn't a good reason for not considering a better solution.

3. The general fact that error messages are usually printed out on two separate lines with repeated heading (for want of a better word) probably is useless and doesn't look nice in most cases; f.ex., have a look at the output of WBRun:
> WBRUN: Can't find "foo".
> WBRUN: object not found
Both lines say the very same thing, with the second one being less informative (but, given that the command accepts only a single file, it would have been sufficient even if it were alone).

4. If one really cared about consistency, then he'd be horrified by the current situation - a few examples:

> WBRun foo
> WBRUN: Can't find "foo".
> WBRUN: object not found

> WBRun
> WBRUN: required argument missing

> List foo
> LIST: No information for "foo".
> LIST: object not found

> Dir foo
> DIR: Could not get information for "foo".
> DIR: object not found

> Copy foo ram:
> Cannot open "foo" for input - COPY: object not found

> Which foo
> WHICH: Could not find "foo".

Note that:
* not all errors, even by the same command, generate 2-line reports (so, it isn't all that true that 2-line printouts are "just the usual way DOS commands have been reporting errors for ages");
* Copy presents 2 messages on the same line, with a heading introducing the second message only, in the middle of the line;
* the usage of strings is not consistent (the first message of Dir and List should have been the same; WBRun and Which say the very same thing using two different strings; "Could not find <path>" would have suited all the commands);
* punctuation is not used consistenly (I'm referring to the dot).

And that's relatively to just the first (and very common) commands that came to mind!

Now, let me clearly repeat that I understand that such cosmetic issues are not a priority and that we can live with them. But please let's not look for excuses ;)
saimoRe: Rename bug20110314 10:24  #2859

I agree on everything, except for the fact that I'm not sure it's a matter of apathy: we all know that resources are little ;)
TrevRe: Rename bug20110314 21:31  #2869

I meant apathy as in settling for the status quo. AmigaOS development practices and resources are a separate issue....
nbacheRe: Rename bug20110314 23:06  #2874
The thing is, it really isn't as simple as it looks.

The message you see in the second line is not defined in the program (in this case C:Rename), but comes from DOS and is therefore translated in dos.catalog. So every program that calls some DOS function and receives some DOS error code, uses the same error message corresponding to that code.

The standard followed by (most? all?) Shell programs when some action involving a DOS call fails is to print a message saying something like "I failed to do what you wanted me to because", and then quote DOS' reason for the failure in the next message; I believe there is some stacking or holding back of errors going on as well, which in the end means the error codes are not necessarily interpreted into messages at the same time as the program's own message is issued (I'm only a beta tester and translator, so I don't know the actual code in dos.library - and if I did, I'm sure I'd wish I didn't ;-)). And when messages are printed, they all get the name of the command prepended, so you can tell which command had the problem; it could be one command line in a long script.

The alternative would be to have the text for every DOS error code inside each catalog for programs that call DOS, and then we poor translators would have to translate them a zillion times ;-).

This is what I meant by "the way it is".

Best regards,

TrevRe: Rename bug20110315 00:34  #2875

RENAME probably does something like this:

success = IDOS->Rename(oldName, newName);

if (!success) {
IDOS->Printf("RENAME: Can't rename \"%s\" as \"%s\" because\n", oldName, newName);
IDOS->PrintFault(IDOS->IoErr(), "RENAME");

Explaining why the file cannot be renamed is user friendly, but the way it's displayed is a little ugly. :-) A global setting that controls error message verbosity would be cool. (Maybe one exists already?)

success = IDOS->Rename(oldName, newName);

if (!success) {
if (verbosity > 0)
IDOS->Printf("RENAME: Can't rename \"%s\" as \"%s\" because\n", oldName, newName);
if (verbosity > 10)
IDOS->PrintFault(IDOS->IoErr(), "RENAME");

I know we can redirect output, and that's great for scripts, but along with a consistent display style, it would be a nice enhancement to the interactive experience.

We used to have an Amiga style guide. Does anything like that exist for AmigaOS 4? Has anyone considered updating and publishing (electronically) the old guide, assuming it's not encumbered by Addison Wesley or Amiga, Inc. copyrights? It's not on the last Amiga Developer CD, unfortunately.
centaurzRe: Rename bug20110315 00:47  #2877
Here's a simple reason why it is better to print the error message on a new line: in some languages (e.g. French), the translated error message cannot be nicely embedded in a user friendly sentence like you would do in Printf("Cannot open file because %m"). So see it as a stand-alone error message.

TrevRe: Rename bug20110315 01:53  #2880

That's only a good reason when the design is poor in the first place, in this case mixing error messages from two different sources. Personally, I would never use "Can't rename \"%1\" to \"%2\" because ..." and expect a system error message to make sense in place of "..." Instead, I would use "Cannot rename %1 to %2. " followed by the system error message, which is hopefully a complete sentence, e.g. "Cannot find the object specified." (In reality, I probably wouldn't even use an application-specific message. I'd just rely on the system message.) If the order of filenames matters in the target language, it's easy to swap the insertion strings, e.g. "Lorem ipsum %2 et %1." Ideally, the strings would use format specifiers specific to ILocale->FormatString() or a similar function where the order of insertion strings is independent of the format string. The same strings can be used by both DOS and the GUI toolkit. I'm sure this is the case is most localized applications. DOS just seems a bit out of touch.
Navigate: 1-15 
Snack! forum website engine, Created in 2008 by Björn Hagström