Scripting Bugs
Re: Scripting Bugs
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)
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)
-
- Site Admin
- Posts: 60357
- Joined: 22 May 2004 16:48
- Location: Win8.1 @100%, Win10 @100%
- Contact:
Re: Scripting Bugs
Confirmed, good find! Thanks.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)
FAQ | XY News RSS | XY Twitter
Re: Scripting Bugs
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:
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.
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;
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
Windows 7/10
Always using the latest stable two-decimal build
Re: Scripting Bugs
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.zer0 wrote:Recently, I came across if not a bug then definitely some unwanted behaviour in the rename scripting command.
That said, I think I'd still consider it a bug unless the "/e" flag is present.
-
- Site Admin
- Posts: 60357
- Joined: 22 May 2004 16:48
- Location: Win8.1 @100%, Win10 @100%
- Contact:
Re: Scripting Bugs
If a file begins with a dot this is not taken as extension but as the file base name.TheQwerty wrote: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.zer0 wrote:Recently, I came across if not a bug then definitely some unwanted behaviour in the rename scripting command.
That said, I think I'd still consider it a bug unless the "/e" flag is present.
FAQ | XY News RSS | XY Twitter
Re: Scripting Bugs
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.admin wrote:If a file begins with a dot this is not taken as extension but as the file base name.TheQwerty wrote: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.zer0 wrote:Recently, I came across if not a bug then definitely some unwanted behaviour in the rename scripting command.
That said, I think I'd still consider it a bug unless the "/e" flag is present.
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
Windows 7/10
Always using the latest stable two-decimal build
-
- Site Admin
- Posts: 60357
- Joined: 22 May 2004 16:48
- Location: Win8.1 @100%, Win10 @100%
- Contact:
Re: Scripting Bugs
Yes, absolutely right. Sorry, it's sunday.zer0 wrote: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.admin wrote:If a file begins with a dot this is not taken as extension but as the file base name.TheQwerty wrote: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.zer0 wrote:Recently, I came across if not a bug then definitely some unwanted behaviour in the rename scripting command.
That said, I think I'd still consider it a bug unless the "/e" flag is present.
FAQ | XY News RSS | XY Twitter
Re: Scripting Bugs
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: 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?
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;
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
Windows 7/10
Always using the latest stable two-decimal build
-
- Site Admin
- Posts: 60357
- Joined: 22 May 2004 16:48
- Location: Win8.1 @100%, Win10 @100%
- Contact:
Re: Scripting Bugs
Yep, bug! Fixed!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: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?Code: Select all
$a = <curfolder>; rename bat, $a;
FAQ | XY News RSS | XY Twitter
-
- Site Admin
- Posts: 60357
- Joined: 22 May 2004 16:48
- Location: Win8.1 @100%, Win10 @100%
- Contact:
Re: Scripting Bugs
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".admin wrote:Yep, bug! Fixed!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: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?Code: Select all
$a = <curfolder>; rename bat, $a;
FAQ | XY News RSS | XY Twitter
Re: Scripting Bugs
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.admin wrote: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".admin wrote:Yep, bug! Fixed!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: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?Code: Select all
$a = <curfolder>; rename bat, $a;
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
-
- Site Admin
- Posts: 60357
- Joined: 22 May 2004 16:48
- Location: Win8.1 @100%, Win10 @100%
- Contact:
Re: Scripting Bugs
Sure, I have fixed that in the meantime.jacky wrote: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.admin wrote: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".admin wrote:Yep, bug! Fixed!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: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?Code: Select all
$a = <curfolder>; rename bat, $a;
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...
FAQ | XY News RSS | XY Twitter
Re: Scripting Bugs
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.admin wrote:A locked Tree should ideally be in synch with the file system.
P.S. This should really be discussed in that other thread
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
Windows 7/10
Always using the latest stable two-decimal build
Re: Scripting Bugs
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).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.
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
Re: Scripting Bugs
I'm gonna stick to the other thread for Lock Tree discussionjacky 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....
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
Windows 7/10
Always using the latest stable two-decimal build