'User menu' command on XP, strange behavior

[otrov]

I installed fresh copy of AS on Windows XP (working through Remote Desktop) and noticed that when I run 'user menu' command on bunch of selected files, it only calls command on first file from selected files. My AS copy on Windows 7 calls 'user menu' command on all selected files:

Code: Select all

call some_program 1st_selected_file
call some_program 2nd_selected_file
call some_program 3rd_selected_file
...

I'm not sure if I'm missing some setting or if there is some problem, but would appreciate help

Thanks

[Petr Solin]

It should run specified command in shell for first name. When command finishes (e.g. when you close started notepad.exe with opened first file), it should run specified command for second name, etc. If you want to run command for all names at once, clear Execute through shell box in User Menu configuration tab.

I have tested it on XP and it works well here, let me know details if it behaves differently.

[otrov]

I made temp folder on Win 7 PC and 9 files inside:

Code: Select all

for /l %x in (1,1,9) do echo %x > %x.txt

I did the same for XP PC

Made 'user menu' command 'type "$(Name)"' with 'Execute through shell' checked, on both PCs

I selected all files and run that command on both PCs. The results are as I would expected - command is called on all selected files, both on 7 and XP in same shell

So, I run again the command I had problem with:

Code: Select all

"C:\Program Files\Calibre2\ebook-convert.exe" "$(Name)" "$(NamePart).mobi"

(It's a converter, part of Calibre package, and I'm converting .epub files to .mobi so I can use them on my device which supports .mobi format)

with 'Execute through shell' on both PCs

On Win 7, shell opens and command is run sequentially on selected files as expected.

On XP only on first file from selected, as reported. If I unchecked 'Execute through shell' then separate shell windows are opened for all selected files and executed in parallel - something I would not like to happen on hungry resource eaters.


Of course this exact problem is trivial, and solved with one line in CLI, but curious what is happening

[edit] Forgot to mention that program 'ebook-convert.exe' is console program, and is frozen Python executable

[Petr Solin]

You can see usermenu.bat file in SAL???.tmp subdirectory of temp folder (%TEMP%). There is list of commands produced by running user-menu command, something like this (here command is "notepad" and I have selected two files: new.txt and new2.txt on path C:\HG):

Code: Select all

@C:
@cd "C:\HG"
call notepad "new.txt"
@C:
@cd "C:\HG"
call notepad "new2.txt"

It seems that ebook-convert.exe causes preliminary ending of this batch file, I don't know reason, probably some special exit code. It seems it depends on Windows version, because Windows 7's version of "call" does not end.

If you would like to experiment with it, you can create and run such batch file, but I don't see any parameters to "call", so I have no idea how to simply bypass this problem. Maybe use some extra batch file to encapsulate ebook-convert.exe (create ebook-convert.bat containing only "ebook-convert.exe %*" or "call ebook-convert.exe %*" and place ebook-convert.bat to user-menu instead of ebook-convert.exe) or start it using "start" with /wait parameter.

[otrov]

Thanks for explanation

I wrapped 'ebook-convert.exe' in batch file but it's same
Whatever. Problem is in 'ebook-convert.exe' and solution should be looked there

BTW, I processed this files earlier today with FOR command (which wasn't terminated):

Code: Select all

for %x in (*.epub) do "C:\Program Files\Calibre2\ebook-convert.exe" "%x" "%~nx.mobi"

[SelfMan]

You can allways use the processmonitor from sysinternals to check whats going on.

[otrov]

I'll let that task to the developer of mentioned program, which I informed, but it seems that he doesn't like Windows OS very much
Cross-platform and 'all OS supported' I imagine sounds tempting to developers, but it seems that many simply claim cross-platform and think that programming language can take care of all OS pairings, without much testing or more knowledge. - This is my general opinion, not necessarily about program I mentioned, but influenced by a another program I run yesterday which trashed my file system with ghost folders, just because it's developer does not understand what he claims - Windows support

Anyway, running procmon on any problem is not very pleasant experience to me. procmon on remote desktop - I'll happily pass

[Ether]

You can try wrapping the call in start /wait command. See start /? for more information.