SC Rename: Script error on <ESC>?

[Filehero]

Hi,

I wonder why I get the following script error upon I hit <ESC> on the rename preview dialog?

SC_rename.png (10.9 KiB) Viewed 660 times

Any ideas?


FH

[TheQwerty]

1) Rename is a command not a function so remove the parentheses around the parameters.
2) You're missing an argument between the 'p' and '1' - it should be the item list.
3) None of that actually matters as I can confirm the same behavior:

Code: Select all

::rename "b", "*_<date dd.mm.yyyy>", "p",,"1";echo 'hi';

I think this is intentional because it comes from a time before functions and back then there was no good way other than prompting to get error messages. The thought being that if the user cancelled the preview & rename it was difficult for the rest of the script to know what to do and proceed accordingly.

Rename should probably be turned into a function and return something meaningful, but I'm not sure what.
Count of items renamed?
Copy of itemlist with the old names replaced by their new ones?
One of the two dependent on a new flag?
Both with the count being the first item in the list?

[Filehero]

Hi TheQwerty,

1) Rename is a command not a function so remove the parentheses around the parameters.

well & yes, I did do my very best to escape from this - albeit explainable - weird distinction, which originates way before I discovered XY and this - sometimes even more fascinating - community. Thanks for the hint.

2) You're missing an argument between the 'p' and '1' - it should be the item list.

True. This shot just snapped one of many param configs I'd tried. But as you already found -> doesn't matter.

3) None of that actually matters as I can confirm the same behavior:

Code: Select all

::rename "b", "*_<date dd.mm.yyyy>", "p",,"1";echo 'hi';

Relief.

Rename should probably be turned into a function and return something meaningful, but I'm not sure what.
Count of items renamed?
Copy of itemlist with the old names replaced by their new ones?
One of the two dependent on a new flag?
Both with the count being the first item in the list?

Fascinating. Sometimes I do have a good idea, but often I don't even have an idea where to start to get good ideas.
Given I could have that choice I vote for the last option, the merger of them all. Three sections separated by a <crlf> with "|"-tokenized lists.

My special thanks for your elaboration regarding the history of this error message. <hatsOffIcon 3>


Cheers,
FeelsbetterHero

[autocart]

I can confirm the same behavior
...
Rename should probably be turned into a function and return something meaningful

+1
please

[PeterH]

I think some time ago we had this problem - it is general...

There are commands, and I also think functions, where
- you might wish to define per option(s) for the cmd/func how to react in case of some error (yes: ESC is kind of error, too)
- how such an error might be signalled to the script
(Also for functions, especially those returning text, it's not good to return an error by some text: it's easy to misunderstand this as valid return value.)
So I think use of XY internal variable(s) to signal return code and descriptive text would be the solution.

I would prefer if this wouldn't be solved command by command, but in general.
(Though maybe implemented command by command )

As long as a script doesn't signal that it will handle errors, it's OK for cmds/funcs to abort script for errors that might lead to "strange" situations.
E.g. a script renaming (with move ) shouldn't delete folders, if the rename has been ESCaped...