Scripting Bugs

Things you’d like to miss in the future...
Twisten
Posts: 204
Joined: 27 Apr 2008 10:30

Re: Scripting Bugs

Post by Twisten »

There's a possible bug when using the rename function
the line: rename s , 'ABCDEFGHIJKLMNOPQRSTUVWXYZ>>abcdefghijklmnopqrstuvwxyz' ;
in my script is expected to change the selected items base name to lower case but fails to change the last letter.
BLAHBLAH.ext is changed to blahblaH.ext instead of the expected blahblah.ext

i bypassed that problem for the time being by using the built in lower case rename function (aaa aa.aaa) but its still wierd since the above script line used to work properly but now seems to have stoped (using xyplorer 8.0 on windows xp pro 32bit)

admin
Site Admin
Posts: 60357
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: Scripting Bugs

Post by admin »

Twisten wrote:There's a possible bug when using the rename function
the line: rename s , 'ABCDEFGHIJKLMNOPQRSTUVWXYZ>>abcdefghijklmnopqrstuvwxyz' ;
in my script is expected to change the selected items base name to lower case but fails to change the last letter.
BLAHBLAH.ext is changed to blahblaH.ext instead of the expected blahblah.ext

i bypassed that problem for the time being by using the built in lower case rename function (aaa aa.aaa) but its still wierd since the above script line used to work properly but now seems to have stoped (using xyplorer 8.0 on windows xp pro 32bit)
Confirmed, good find! Thanks.

zer0
Posts: 2673
Joined: 19 Jan 2009 20:11

Re: Scripting Bugs

Post by zer0 »

Recently, I came across if not a bug then definitely some unwanted behaviour in the rename scripting command.

To reproduce:
a) Create a random test file. Remove its base name, so it's called ".<ext>"
b) Copy to clipboard a name that you wish to call it, such as "Temp"
c) Select that extension-only file and run this script on it:

Code: Select all

$a = <clipboard>;
 rename b, $a;
The outcome is that your file will be called "Temp" (or whatever it is that you copied to clipboard) and have no extension. This is undesirable because a) I'd rather it append "Temp" to that file, so it's called "Temp.<ext>" b) I didn't add a scripting command to remove the extension as well. It also means that there's no way to append using rename to files that have only the extension.

EDIT: I also have "Exclude extension on rename" ticked in my Config, so that's another reason why I wasn't expecting what happened.
Reporting a bug? Have a wish? Got a question? Use search - View roadmap - FAQs: Forum + XY site
Windows 7/10
Always using the latest stable two-decimal build

TheQwerty
Posts: 4373
Joined: 03 Aug 2007 22:30

Re: Scripting Bugs

Post by TheQwerty »

zer0 wrote:Recently, I came across if not a bug then definitely some unwanted behaviour in the rename scripting command.
It's not a scripting bug, but rather the way Batch Rename functions; if you attempt to do the same rename via the Rename Special dialog it does the same thing.

That said, I think I'd still consider it a bug unless the "/e" flag is present.

admin
Site Admin
Posts: 60357
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: Scripting Bugs

Post by admin »

TheQwerty wrote:
zer0 wrote:Recently, I came across if not a bug then definitely some unwanted behaviour in the rename scripting command.
It's not a scripting bug, but rather the way Batch Rename functions; if you attempt to do the same rename via the Rename Special dialog it does the same thing.

That said, I think I'd still consider it a bug unless the "/e" flag is present.
If a file begins with a dot this is not taken as extension but as the file base name.

zer0
Posts: 2673
Joined: 19 Jan 2009 20:11

Re: Scripting Bugs

Post by zer0 »

admin wrote:
TheQwerty wrote:
zer0 wrote:Recently, I came across if not a bug then definitely some unwanted behaviour in the rename scripting command.
It's not a scripting bug, but rather the way Batch Rename functions; if you attempt to do the same rename via the Rename Special dialog it does the same thing.

That said, I think I'd still consider it a bug unless the "/e" flag is present.
If a file begins with a dot this is not taken as extension but as the file base name.
Reality begs to differ. A file called ".txt" has "Text Document" in the "Type" column and has a normal TXT file icon. Also, an Apache distributed config file is called ".htaccess" (HTACCESS in the "Type" column) and in that situation dot cannot be treated as file base name, yet the "htaccess" part can be changed. This in turn proves that it's the extension and dot is the separator.
Reporting a bug? Have a wish? Got a question? Use search - View roadmap - FAQs: Forum + XY site
Windows 7/10
Always using the latest stable two-decimal build

admin
Site Admin
Posts: 60357
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: Scripting Bugs

Post by admin »

zer0 wrote:
admin wrote:
TheQwerty wrote:
zer0 wrote:Recently, I came across if not a bug then definitely some unwanted behaviour in the rename scripting command.
It's not a scripting bug, but rather the way Batch Rename functions; if you attempt to do the same rename via the Rename Special dialog it does the same thing.

That said, I think I'd still consider it a bug unless the "/e" flag is present.
If a file begins with a dot this is not taken as extension but as the file base name.
Reality begs to differ. A file called ".txt" has "Text Document" in the "Type" column and has a normal TXT file icon. Also, an Apache distributed config file is called ".htaccess" (HTACCESS in the "Type" column) and in that situation dot cannot be treated as file base name, yet the "htaccess" part can be changed. This in turn proves that it's the extension and dot is the separator.
Yes, absolutely right. Sorry, it's sunday. :)

zer0
Posts: 2673
Joined: 19 Jan 2009 20:11

Re: Scripting Bugs

Post by zer0 »

I have a script command that renames a file as the folder that it is in. However, as I've discovered, running this command also refreshes the Tree, even if the Tree is locked. I have looked in XY's Help file and changelog and do not see any form of explanation why this should happen. It shouldn't, because renaming a file based on its folder shouldn't have anything to do with the Tree.

To reproduce:
1. Go into a folder that has no nested folder. Lock the Tree.
2. Create a folder, name makes no difference. Go into it.
3. Create a file in that folder. Run the script below on that file:

Code: Select all

$a = <curfolder>;
    rename bat, $a;
File will be renamed, but the locked Tree will re-sync and show that new folder that you created in (2). Why is the Tree getting involved when a command that doesn't request any information from it is run in the List? :?
Reporting a bug? Have a wish? Got a question? Use search - View roadmap - FAQs: Forum + XY site
Windows 7/10
Always using the latest stable two-decimal build

admin
Site Admin
Posts: 60357
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: Scripting Bugs

Post by admin »

zer0 wrote:I have a script command that renames a file as the folder that it is in. However, as I've discovered, running this command also refreshes the Tree, even if the Tree is locked. I have looked in XY's Help file and changelog and do not see any form of explanation why this should happen. It shouldn't, because renaming a file based on its folder shouldn't have anything to do with the Tree.

To reproduce:
1. Go into a folder that has no nested folder. Lock the Tree.
2. Create a folder, name makes no difference. Go into it.
3. Create a file in that folder. Run the script below on that file:

Code: Select all

$a = <curfolder>;
    rename bat, $a;
File will be renamed, but the locked Tree will re-sync and show that new folder that you created in (2). Why is the Tree getting involved when a command that doesn't request any information from it is run in the List? :?
Yep, bug! Fixed!

admin
Site Admin
Posts: 60357
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: Scripting Bugs

Post by admin »

admin wrote:
zer0 wrote:I have a script command that renames a file as the folder that it is in. However, as I've discovered, running this command also refreshes the Tree, even if the Tree is locked. I have looked in XY's Help file and changelog and do not see any form of explanation why this should happen. It shouldn't, because renaming a file based on its folder shouldn't have anything to do with the Tree.

To reproduce:
1. Go into a folder that has no nested folder. Lock the Tree.
2. Create a folder, name makes no difference. Go into it.
3. Create a file in that folder. Run the script below on that file:

Code: Select all

$a = <curfolder>;
    rename bat, $a;
File will be renamed, but the locked Tree will re-sync and show that new folder that you created in (2). Why is the Tree getting involved when a command that doesn't request any information from it is run in the List? :?
Yep, bug! Fixed!
Looks like this was not a bug. A locked Tree should ideally be in synch with the file system. So I will have to remove that "fix".

jacky
XYwiki Master
Posts: 3106
Joined: 23 Aug 2005 22:25
Location: France
Contact:

Re: Scripting Bugs

Post by jacky »

admin wrote:
admin wrote:
zer0 wrote:I have a script command that renames a file as the folder that it is in. However, as I've discovered, running this command also refreshes the Tree, even if the Tree is locked. I have looked in XY's Help file and changelog and do not see any form of explanation why this should happen. It shouldn't, because renaming a file based on its folder shouldn't have anything to do with the Tree.

To reproduce:
1. Go into a folder that has no nested folder. Lock the Tree.
2. Create a folder, name makes no difference. Go into it.
3. Create a file in that folder. Run the script below on that file:

Code: Select all

$a = <curfolder>;
    rename bat, $a;
File will be renamed, but the locked Tree will re-sync and show that new folder that you created in (2). Why is the Tree getting involved when a command that doesn't request any information from it is run in the List? :?
Yep, bug! Fixed!
Looks like this was not a bug. A locked Tree should ideally be in synch with the file system. So I will have to remove that "fix".
hmm... ideally though, there's no reason to add the node (visible) on the Tree, just add the plus sign to its parent. IOW add the node to the parent (upon folder creation), but do not expand the parent.
Since, if that folder existed before hand, that is what it would be like: a plus sign on the parent, but no expansion when we go deep into subfolders. And a locked Tree (while in synch) does not auto-expand...
Proud XYplorer Fanatic

admin
Site Admin
Posts: 60357
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: Scripting Bugs

Post by admin »

jacky wrote:
admin wrote:
admin wrote:
zer0 wrote:I have a script command that renames a file as the folder that it is in. However, as I've discovered, running this command also refreshes the Tree, even if the Tree is locked. I have looked in XY's Help file and changelog and do not see any form of explanation why this should happen. It shouldn't, because renaming a file based on its folder shouldn't have anything to do with the Tree.

To reproduce:
1. Go into a folder that has no nested folder. Lock the Tree.
2. Create a folder, name makes no difference. Go into it.
3. Create a file in that folder. Run the script below on that file:

Code: Select all

$a = <curfolder>;
    rename bat, $a;
File will be renamed, but the locked Tree will re-sync and show that new folder that you created in (2). Why is the Tree getting involved when a command that doesn't request any information from it is run in the List? :?
Yep, bug! Fixed!
Looks like this was not a bug. A locked Tree should ideally be in synch with the file system. So I will have to remove that "fix".
hmm... ideally though, there's no reason to add the node (visible) on the Tree, just add the plus sign to its parent. IOW add the node to the parent (upon folder creation), but do not expand the parent.
Since, if that folder existed before hand, that is what it would be like: a plus sign on the parent, but no expansion when we go deep into subfolders. And a locked Tree (while in synch) does not auto-expand...
Sure, I have fixed that in the meantime. :)

zer0
Posts: 2673
Joined: 19 Jan 2009 20:11

Re: Scripting Bugs

Post by zer0 »

admin wrote:A locked Tree should ideally be in synch with the file system.
The locked (Maxi) Tree should be the locked Tree and then user can "unlock" it bit by bit with various settings. True lock should still be achievable though. Otherwise, Lock Tree might as well be broken down into "Do not auto scroll" and "Do not auto-expand" since those 2 appear to be the only limitations unless otherwise specified.

P.S. This should really be discussed in that other thread :lol: :oops:
Reporting a bug? Have a wish? Got a question? Use search - View roadmap - FAQs: Forum + XY site
Windows 7/10
Always using the latest stable two-decimal build

jacky
XYwiki Master
Posts: 3106
Joined: 23 Aug 2005 22:25
Location: France
Contact:

Re: Scripting Bugs

Post by jacky »

zer0 wrote:Otherwise, Lock Tree might as well be broken down into "Do not auto scroll" and "Do not auto-expand" since those 2 appear to be the only limitations unless otherwise specified.
Yes, that is exactly what locked Tree means, no auto-scroll & no auto-expand (which means no keep in sync with user browsing, but still in synch with the filesystem of course).

Seems you have your own vision of what a locked Tree should be, but that's not what it actually is/should be. And remember that what we call today "Lock Tree" used to be, only working in reverse, "Auto-Synchronize Tree".
That was, and remains, the original intent : disable the auto-sync of the Tree with the user's browsing, so one can go elsewhere deep down in a folder structure, without the need for the Tree to scroll & expand many nodes when it is unnecessary....
Proud XYplorer Fanatic

zer0
Posts: 2673
Joined: 19 Jan 2009 20:11

Re: Scripting Bugs

Post by zer0 »

jacky wrote:Yes, that is exactly what locked Tree means, no auto-scroll & no auto-expand (which means no keep in sync with user browsing, but still in synch with the filesystem of course).

Seems you have your own vision of what a locked Tree should be, but that's not what it actually is/should be. And remember that what we call today "Lock Tree" used to be, only working in reverse, "Auto-Synchronize Tree".
That was, and remains, the original intent : disable the auto-sync of the Tree with the user's browsing, so one can go elsewhere deep down in a folder structure, without the need for the Tree to scroll & expand many nodes when it is unnecessary....
I'm gonna stick to the other thread for Lock Tree discussion :wink:
Reporting a bug? Have a wish? Got a question? Use search - View roadmap - FAQs: Forum + XY site
Windows 7/10
Always using the latest stable two-decimal build

Post Reply