Error messages are not colored at all

[hupfdule]

Error messages are arguably the most important messages and therefore should receive the most prominent color. At the moment they are not colored at all and can therefore be easily overlooked.

Usually error messages are printed in "red". As red is already used for deletion of files that imposes a conflict. The options I see are:

• Use a different color than red for errors (e.g. magenta)
• Use a different color for deletions and use red for errors
• Use bold red for errors

From those option the second one appeals most to me, but I think you should take the actual decision how to handle this.

A (not very unlikely) error can be, for example, missing write permissions.

A second issue with error messages (which is related to this one; therefore I don't open a second issue for that one) is that only the original filename is visible, not the operation that should be applied nor the resulting filename (if applicable). For example the message

Create dir for some file ERROR: Can not write in documents

is printed when trying to rename the file "some file" in the directory "documents".

• The error message itself is a bit misleading (as it states "Create dir for").
• It is not clear whether the file should have been renamed, deleted or copied.
• The target file name (for renaming or copying) is not visible.
• The file names are not separated enough from the error messages, this is especially true for file names containing spaces (this is related to #14).

Therefore the error message should be improved (if possible) and the failed operation (with the involved file names) should be written out (in the same format as the successful output, but clearly differentiated so that it is clear that this is a failed operation).

[bulletmark]

Your opening statement here is "At the moment they are not colored at all" which is not correct. Error messages are colored according to the operation (i.e. remove, rename, copy). You then say "Usually error messages are printed in red" which is not correct either, 99.9% of Linux command line apps do not use color at all.

The philosophy I have chosen for this app is:

1. Color is used to distinguish the operation, i..e. remove = red, rename = yellow, copy = green.
2. Errors are output in the same color as the operation they pertain to but all errors are printed with an "ERROR:" preface in the text message and the process return code is set to error as expected for all well-behaving Linux command line apps.

I'm sorry but I think the above is better than any of the alternatives you propose.

Regarding your second issue here, I disagree that the error is not clear. If I am trying to rename afile to adir/afile1 but adir is not writable by me then the error is:

Create dir for afile ERROR: Can not write in adir

Fundamentally the error is that you can not write inadir and that is very clearly stated. Whether the original file name that you are changing from, or the target file name you are changing to, are printed in the error message is merely opinion and plenty would disagree with you. We know the original file name must be unique but we don't know that for the target file name so that is why the original name is output.

The issue about columns for file names is irrelevant here given you have raised issue #14 about it.