Topic: unmentioned changes from 2.01 to 3.0 (and porting issues)

I'm a long time Siren user on Windows.  I was happy to see the new version 3.0 with support for additional file types, like .3gp and .mp4.

However, it took some time to port my scripts and batch files from Siren 2.01 to Siren 3.0.  Some change items didn't seem to be listed in the history, especially for command line. So it may be helpful to add these to the history of changes for others looking to port from Siren 2.0(1).

Some of the items that I found:

Command line argument deliminator changes from "\" to "-" or "--" for long form.

Command line options are case sensitive, and many changes case from UPPER to LOWER in 3.0. For example,  "\E" worked in 2.01, but is not recognized in 3.0, replaced with "-e", also true for /R, /Q, etc.

/I option (specifying INI file) is gone.  Seemingly, so is INI file support. Where do settings go now, registry?

Command line arguments seem to be order sensitive in a way that they were not in 2.0.    Specifically, the "-r" "-q" options did not seem to work when placed at end of options, but they do work when placed at the beginning of options list. When at the end, the rename and quit functions did not work, i.e  "Siren.exe -e blah -f blah -d blah -r -q" did not work, but "Siren.exe -r -q -e blah -f blah -d blah"

Re: unmentioned changes from 2.01 to 3.0 (and porting issues)

Hello and welcome,

You're right version 2-3 changes associated to command line usage have not been listed.

jkane wrote:

Command line argument deliminator changes from "\" to "-" or "--" for long form.

Under windows, the standard option prefix is "/" (not "\"). It is the only one authorized by Siren 2.
As Siren3 is multiplatform you can use "-" or "/".
I did not specify this in the Help but you can see it in the command line usage : siren /h
I'll add this in the "History" page.

jkane wrote:

Command line options are case sensitive, and many changes case from UPPER to LOWER in 3.0. For example,  "\E" worked in 2.01, but is not recognized in 3.0, replaced with "-e", also true for /R, /Q, etc.

You are right. I'll add this in the "History" page.

jkane wrote:

/I option (specifying INI file) is gone.

The "/I" parameter has been changed to "/P" because the "ini" extension is Windows centric and I wanted something more generic.
I'll add this in the "History" page.

jkane wrote:

Seemingly, so is INI file support. Where do settings go now, registry?

No change have been done here.
By default the "siren.ini" is located in the executable directory and contains all settings.

jkane wrote:

Command line arguments seem to be order sensitive in a way that they were not in 2.0.    Specifically, the "-r" "-q" options did not seem to work when placed at end of options, but they do work when placed at the beginning of options list. When at the end, the rename and quit functions did not work, i.e  "Siren.exe -e blah -f blah -d blah -r -q" did not work, but "Siren.exe -r -q -e blah -f blah -d blah"

I've just made some tests and did not see any problem.
Can you post an example ?

Regards,

Remi

Re: unmentioned changes from 2.01 to 3.0 (and porting issues)

Modifications have been done in the History page.

Thanks for your remarks

Re: unmentioned changes from 2.01 to 3.0 (and porting issues)

Remi,

Thanks for your fast response, and for making the changes to History. I think this will be helpful to others who are porting to 3.0.

Under windows, the standard option prefix is "/" (not "\"). It is the only one authorized by Siren 2.
As Siren3 is multiplatform you can use "-" or "/".
I did not specify this in the Help but you can see it in the command line usage : siren /h

Sorry, I had a typo on the "\". Initially I thought that the slash was the problem in my statements, but in reality it was the capital versus lower case. So this is cleared up for me.  However, on a command line "siren /h" does not list "-" as an option delimiter. For example,  for rename, it lists  "/r", and "--rename", but does not list "-r".

As for the option order issue:

I've just made some tests and did not see any problem.
Can you post an example ?

Actually, I did some more tests from straight command line and they seemed to work. However, I am calling from inside a batch file and see the issue.

I have two batch  files.  Batch File 1 (Batch1) runs and does a CALL to Batch File 2 (Batch2), and passes a directory in the first batch parameter.  Batch2 contains a siren rename command line.  The CALL command from the first batch file works in a similar fashion to Start /Wait. Batch 1 will wait for Batch 2 to complete for continuing.

Batch2 has a command line like this:

"C:\Program Files (x86)\Siren\Siren.exe" -e %%Xddd-%%Xfs-00MAS-%%N1.%%e -s img_*.jpg -d %1 -f *.* -r -q

This worked in Siren 2.0 (with capitals for options).  With Siren 3, Siren window loaded and stayed open. The "new filename" showed the future name for the files, but the rename action didn't take place, and Siren didn't quit.  After some testing, I c moved the -r and -q to the beginning of the option string, like this:

"C:\Program Files (x86)\Siren\Siren.exe" -r -q -e %%Xddd-%%Xfs-00MAS-%%N1.%%e -s img_*.jpg -d %1 -f *.*

And after making this change, Siren renamed the files and quit. Maybe there is something more complicated going on because of the batch file calls.  I think I also tried using "Start /wait" method, with the same results.

I will have to do some more testing, but the batch files are at least running again.

Re: unmentioned changes from 2.01 to 3.0 (and porting issues)

Hi,

jkane wrote:

However, on a command line "siren /h" does not list "-" as an option delimiter.

The output displays the default short option delimiter of the current platform. Under Windows it is "/".
Note that many standard Windows commands do the same. For example "ipconfig -all" works the same as "ipconfig /all" even if the help shows only "ipconfig /all".

I've just made a test with a ".bat" file containing the following line :
Siren -e %%Xddd-%%Xfs-00MAS-%%N1.%%e -s img_*.jpg -d %1 -f *.* -r -q

It worked as expected (note that "-f *.*" is useless because it is equivalent to "no filter").

The machine I currently use is under XP SP3.
I noticed that under different Windows versions the interpretation of "%" can change.
Siren 3 command line parser is different than Siren 2 one. So it can be linked to this too.

6 (edited by Stefan 2012-07-19 12:48:40)

Re: unmentioned changes from 2.01 to 3.0 (and porting issues)

Question:

Could it be that the %1-Path string is too long, so the rest of the command line gets cut?
If yes, you can use SUBST to shorten the path first.

(I googled for an better description and maybe this will help to understood (join the lines first):

http://
superuser.com/
questions/37737/
how-do-i-extend-the-maximum-file-path-size-in-windows-7)



My thought:

That cut would be no matter for the trailing "-f *.*" part
(see Rémi comment above) in the second example.

But for the trailing " -r -q" part in the first example this would matter.



Siren -e %%Xddd-%%Xfs-00MAS-%%N1.%%e -s img_*.jpg -d %1 -f *.* -r -q
Siren -e %%Xddd-%%Xfs-00MAS-%%N1.%%e -s img_*.jpg -d X:\Very\Very\LongPath -f *.* -r -q

Siren -r -q -e %%Xddd-%%Xfs-00MAS-%%N1.%%e -s img_*.jpg -d %1 -f *.*
Siren -r -q -e %%Xddd-%%Xfs-00MAS-%%N1.%%e -s img_*.jpg -d X:\Very\Very\LongPath -f *.*


.

Re: unmentioned changes from 2.01 to 3.0 (and porting issues)

Remi,


I am using Windows 7 x64, so that is another variable from your test.  I think as you mention there must be some interaction with new command line parser and maybe windows 7.

Since I got it to work I haven't played around with it too much more to see if I can isolate it further.

Stephan,

The issue is not with a long path name in the -d %i1.   (And by the way, this issue still occurs when I replace the batch parameter "%1" with a hardcoded path). And the path itself is very short anyway.

Plus, I think that  that Siren 'receives' the right directory, because it loads that directory as it executes the command line, and shows the preview of the rename operation. But it just sits idle and doesn't rename or quit. So I think this means that all commands (other than /r /q) were received/processed by siren.

Re: unmentioned changes from 2.01 to 3.0 (and porting issues)

I've made some tests under 7 64 bit and all went fine.

Another idea : /r is the 9th parameter of the command line (10th if counting siren). Depending on how you build your command  it could be linked to parameter substitution.

Stefan's idea can be interesting to follow too.