Having problems with the foreach function

[Mesh]

I'm having problems after making my first forays into using the "foreach" function. Before claiming a bug, I'd like someone to look over my code and tell me if I'm making a mistake in my implementation.

Here's a test script:

Code: Select all

// Test Script - takes a file like "the before.txt" and *should* rename it to "The After - the before.txt"
	
	foreach($token, <get selecteditemspathnames |>)
	{
	
	
		//  Copy filename to variables.
		set $work_name, <curname>;

		//  Set variable to store orig filename.
		set $work_origname, <curname>;


		regexreplace $work_name, $work_name, "before", "after";
		regexreplace $work_name, $work_name, "\.txt", "";
	
	
		//  Workaround to change case for the title to Title Case.
		rename re, "^.*>>$work_name";
		#126;
		set $work_name, <curname>;
		
	
		//  Final file rename - re-attach original name.
		rename re, "^.*>>$work_name - $work_origname";
		
	}
	

This script takes a file like "the before.txt" and *should* rename it to "The After - the before.txt"

Now, here's what's going on. If I run this on a single file, it works exactly as it should. But if I run it on more than one file, let's say "the before 1.txt" and "the before 2.txt", I get a whole string of errors that it can't rename one of the files because it would collide with an existing file.

It's acting like it's working on the second file before it's finished processing the first, which would - of course - cause problems.

Can someone tell me if I'm making a mistake, or if the foreach function is buggy?

[nas8e9]

Now, here's what's going on. If I run this on a single file, it works exactly as it should. But if I run it on more than one file, let's say "the before 1.txt" and "the before 2.txt", I get a whole string of errors that it can't rename one of the files because it would collide with an existing file.

It's acting like it's working on the second file before it's finished processing the first, which would - of course - cause problems.

It sounds like the rename operation is happening out-of-order, which might be caused by background processing?

[Mesh]

It sounds like the rename operation is happening out-of-order, which might be caused by background processing?

I didn't think about background processing, but none of these operations would have any significant lag time. Not to mention, the expectation is that XY would not move to the next iteration of the loop until the last one finished properly. So, if that's the case, it would definitely qualify as a bug, I think.

[nas8e9]

It sounds like the rename operation is happening out-of-order, which might be caused by background processing?

I didn't think about background processing, but none of these operations would have any significant lag time. Not to mention, the expectation is that XY would not move to the next iteration of the loop until the last one finished properly. So, if that's the case, it would definitely qualify as a bug, I think.

Yes and no: while the original XYcopy was under development, there were some rather terse reports of users who had scripts that performed deletes after copy/moves and found that that order was no longer adhered to with background processing enabled. Since then, the command

Code: Select all

setting "BackgroundFileOps", 0;

can be used to disable background processing for the duration of the script execution. Using the above command will not persist the setting; should you want to persist it,

Code: Select all

setting "BackgroundFileOps", 0, p;

can be used or

Code: Select all

settingp

instead of

Code: Select all

setting

.

It's a known gotcha that, as far as I can tell, isn't yet properly warned about in the help file for the copy, copyas, etc. scripting commands. Since Don plans to make it the factory default, I do hope the help file will be updated to include such warnings.

[tiago]

And this will solve your problem, with a little hints too.
The most important being: when your working with foreach, ensure XYplorer will work with one item at a time (selfilter is your friend, pal).

Code: Select all

// Test Script - takes a file like "the before.txt" and *should* rename it to "The After - the before.txt"
   
   foreach($token, <get selecteditemsnames |>)

   {
   
      //  Copy filename to variables.
      selfilter """$token"""; //ensure no similar names get selected to get the job done
      #1048; //ensure the selected item is also focused

      set $work_name, <curbase>; // $work_name=%26lt%3Bcurbase%26gt%3B%3B //easier
      $ext = <curext>; //will be useful later to preserve extension
      //  Set variable to store orig filename.
      set $work_origname, <curbase>; // $work_origname=%26lt%3Bcurbase%26gt%3B%3B //easier

      regexreplace $work_name, $work_name, "before", "after";
//      regexreplace $work_name, $work_name, "\.txt", ""; //replaced!  =)
   
   
      //  Workaround to change case for the title to Title Case.
      $work_name=recase%28%26quot%3B%24work_name%26quot%3B%2C "title");
//      #126; //recase //replaced!  =)
//      set $work_name, <curbase>; // obsolete
      
   
      //  Final file rename - re-attach original name.
      rename re, "^.* > $work_name - $work_origname.$ext"; // you should check your separators, but this may be my config...
      
   }

   status "Job done."

[Mesh]

I tried disabling the background file ops, as well as the suggestion to use selfilter.

Disabling background file ops didn't change anything. And selfilter simply made the script fail with an error that nothing was selected.

Stepping through the script, however, shows something very odd - because I'll be going through the first cycle, so it's working on the first file. When I get to the last rename line (I replaced the earlier rename operation with "recase" - thanks for that!) - that's when the errors start triggering, and it's saying that it can't rename the *second* file because it would conflict with the first. And yet they don't have the same file name, so I have no idea why this is failing.


This is the current version of the code I'm using:

Code: Select all

// Test Script - takes a file like "the before.txt" and *should* rename it to "The After - the before.txt"
	
	// Temporarily disable background file processing.
	setting "BackgroundFileOps", 0;


	foreach($token, <get selecteditemspathnames |>)
	{

	
		//  Copy filename to variables.
		set $work_name, <curname>;

		//  Set variable to store orig filename.
		set $work_origname, <curname>;


		regexreplace $work_name, $work_name, "before", "after";
		regexreplace $work_name, $work_name, "\\.txt", "";
	
	
		//  Workaround to change case for the title to Title Case.
		// rename re, "^.*>>$work_name";
		// #126;
		// set $work_name, <curname>;
		$work_name = recase($work_name, "title", 1);
		
	
		//  Final file rename - re-attach original name.
		rename re, "^.*>>$work_name - $work_origname";
		
	}
	
	
	// Restore the original state of background file processing.
	setting "BackgroundFileOps", r;
	

[admin]

Please explain in general terms what kind of rename operation you are trying to make, and what are the filenames you are going to rename.

[admin]

It's a known gotcha that, as far as I can tell, isn't yet properly warned about in the help file for the copy, copyas, etc. scripting commands. Since Don plans to make it the factory default, I do hope the help file will be updated to include such warnings.

Difficult. I have learned that the Help file is not a place where people find things. They don't even look there. I will rather rethink the decision to make it factory default. Thanks for the reminder.

[nas8e9]

It's a known gotcha that, as far as I can tell, isn't yet properly warned about in the help file for the copy, copyas, etc. scripting commands. Since Don plans to make it the factory default, I do hope the help file will be updated to include such warnings.

Difficult. I have learned that the Help file is not a place where people find things. They don't even look there. I will rather rethink the decision to make it factory default. Thanks for the reminder.

This *may* be the exception to that rule in the sense that people starting out with scripting, have no choice but to look up the commands in the help file; even more experienced scripters will probably need reminding of the parameters when creating a new script.

As for keeping background operations non-default, I do think that would be a pity given its value as well as the support load (longer file operations blocking the UI comes up with some regularity in the forums; I don't know whether it features in the e-mail support).

[Mesh]

Please explain in general terms what kind of rename operation you are trying to make, and what are the filenames you are going to rename.

This test script is a stripped down version of the real one I was working with. When I experienced this issue, I stripped out most of the extraneous operations to make it easier to duplicate and demonstrate this issue.

This script will take the original filename, and prefix it with a modified version of the information in the original name, while keeping the original name intact. Here is what the script *should* be doing (which it does just fine if you only use it on a single file):


Original Files:

the before 1.txt
the before 2.txt


What they should be after renaming:

The After 1.txt - the before 1.txt
The After 2.txt - the before 2.txt

[admin]

It's a known gotcha that, as far as I can tell, isn't yet properly warned about in the help file for the copy, copyas, etc. scripting commands. Since Don plans to make it the factory default, I do hope the help file will be updated to include such warnings.

Difficult. I have learned that the Help file is not a place where people find things. They don't even look there. I will rather rethink the decision to make it factory default. Thanks for the reminder.

This *may* be the exception to that rule in the sense that people starting out with scripting, have no choice but to look up the commands in the help file; even more experienced scripters will probably need reminding of the parameters when creating a new script.

As for keeping background operations non-default, I do think that would be a pity given its value as well as the support load (longer file operations blocking the UI comes up with some regularity in the forums; I don't know whether it features in the e-mail support).

In the meantime I have added something to the Help file. Maybe somebody finds it.

[nas8e9]

In the meantime I have added something to the Help file. Maybe somebody finds it.

Does that mean that background processing enabled, will become the factory default?

[admin]

In the meantime I have added something to the Help file. Maybe somebody finds it.

Does that mean that background processing enabled, will become the factory default?

Yes. It is already in the current beta.

[nas8e9]

In the meantime I have added something to the Help file. Maybe somebody finds it.

Does that mean that background processing enabled, will become the factory default?

Yes. It is already in the current beta.

Missed the beta changelog, sorry.

[tiago]

Not having an answer is a bad thing.
But having it and ignoring it for the wrong reason is worse.
Mesh, I'll try the other way:

v9.90.0304 - 2011-02-13 11:26
+ Scripting: Added foreach loops.

What's the reason for a "foreach" command?
To use a sequence of commands in each listed items one at a time, being $token the indicator of what file will be processed that time.

Example 3:
// selected list items
foreach($token, <get selecteditemspathnames |>) {
echo $token;
}

As you can see, echo $token; tells the script that it will pick up an item and echo it, one after each other despite all of the selected items being listed via selecteditemspathnames. This is key.

If you had problems with focus, solve the problem with focus - my method is to use #1048/9 depending on the case, since I saw the (my?) system making XY losing focus for several almost imperceptive reasons and that method solved ALL of my issues.

I should also point that """selfilter""" has completely different effect than "selfilter", and if (which I don't believe, because my version of your script works 100% of the times, it's not a theoretical solution, it's a WORKING SOLUTION) this is not working for you, I'd like to suggest you to try selecitems, which in its turn perform awesomely under specific situations, as I'm learning.

You clearly state that your script, modified or not, have problems with attempts of items being renamed simultaneously, and that is caused by the bad understanding and usage you're making out of the command, which I expect to have enlightened now.

In the other hand: why are you using foreach, if you're processing the same batch of files all at once? See? Analyze the whole script in action with step mode (I know it's a tedious task sometimes, there should be a way to review what was done in a previous task just like a way to jump 4 or 5 or 80 executions/loops in some occasions, but that's the only way ) and you'll see there's no logic in the way you're doing it.

Try it again.

I know how frustrating is not to have an answer, but it's more frustrating trying to help and having your efforts falling into the void. Yes, I see you made usage of my advices, what I'm saying is: it works, it solved your problem and probably you're not going to have better luck than this.

Hope this time it helps.