Another WinRAR command question

[Ross]

Everyone has files and folders that cannot be deleted, maybe they're memories of something, but they do take a lot of space and are nasty to backup on the cloud, since the upload of each individual file takes a time to start. That's why I've set some commands to use WinRAR inside xplorer².
One of them is:

Code: Select all

Name: Compact in RAR, using current folder's name
> "C:\Program Files\WinRAR\WinRAR.exe" a "$C" $S

So if a have my C: drive with a folder named "parent", with contains three files inside, like child1.txt, child2.mp3 and child3.pdf, I press Ctrl+A to select them all then run that command. Result: the fourth file named "parent.rar" will be created inside the "parent" folder.

But actually this parent.rar is supposed to replace the 'parent' folder, so I'd like to have it in the same level as the folder, such as C:\parent.rar and not C:\parent\parent.rar.

What modifications should I do in the above command?
Thanks

[FrizzleFry]

try:
> "C:\Program Files\WinRAR\WinRAR.exe" a "..\$C" $S

this will probably fail if you run it from the root folder of a drive

[Ross]

Thanks FrizzleFry! Worked as expected.
Just one more little thing: let's say now I'm on the parent folder, and there is the 'child' folder, containing "grandchild1.txt", "grandchild3.txt", "grandchild3.txt". but since I'm not in the child folder, then I don't see those three files. I'd like to select the child folder (marking it with the blue cursor, not only focusing) and pack it in rar, leaving the child.rar in the same level alongside with 'child' folder. How do I do it?

[FrizzleFry]

try
> "C:\Program Files\WinRAR\WinRAR.exe" a "$N" "$N"
or
> "C:\Program Files\WinRAR\WinRAR.exe" a "$N" $S

[Ross]

They both worked perfectly. What's the practical difference between $N and $S in that case?
Thanks a lot Frizzle, that meant a lot to me!

[FrizzleFry]

If you only have one file/folder selected they are basically the same... except $S includes quotes if necessary...
$N gives you the name of the focused item and it is set even if nothing is selected... $S gives the names of all selected items...
so if you have several items selected the first command would only rar the last item selected (usually)... the second command would rar up all the selected items...

[Ross]

I got it. It's the old difference between 'focused' and 'selected' Thanks!

[Ross]

I decided to bump this to avoid opening another topic to address a very similar issue.
I reverted my OS to Windows 7 from Windows 8, and imported my Winrar custom commands list. One of the examples I have is:

Create RAR archive, using current dir's name, on opposing pane
> "C:\Program Files\WinRAR\WinRAR.exe" a -r -ep1 "$I\$C.rar" $S

This would be very useful to create long backups. But, I created a test folder with some dummy files to test it, and guess what, it will pack all the files but the last in the list. Yes, I hit Ctrl+A to select all before firing the keyboard shortcut to run the above command.

Other similar command has the same problem:

Create RAR archive, asking for filename, and store in current folder (not oposing pane)
> rar.exe a -r -ep1 "$?.rar" $S

Changing from Winrar (the program with a GUI) to RAR.exe (the command line executable) won't help.

Incredibly, this one works fine:

Create RAR archive, asking for filename, in opposing pane
> "C:\Program Files\WinRAR\WinRAR.exe" a -r -ep1 "$I"\"$?" $S

How can I fix the two first commands?

Thanks!

[Kilmatead]

There is nothing wrong with those commands (I just created user-commands for all of them and they respond as expected) - so something else must be interfering with your pane selections.

Try substituting $A for $S, and see if it makes a difference (it passes the same selections, except $A adds full paths to each element, which should make no difference to WinRAR, but may to anything interfering with your selections).

If this happens with $A as well, then as a last test, try selecting your files and typing "$ $>" into the addressbar and hitting <Enter> - your selections should open in your default text editor. This is just a more immediate way of checking that all your selections were indeed "seen" by x2 without some gremlin snagging them.

I suspect you may have some sort of "helper" programme installed which monitors keystrokes, or file-selections (from explorer) for shortcuts/additional menus? Anything like that sound familiar?

[FrizzleFry]

If you select enough files you will run into the command line length limit (8191) even using $S which only sends the filenames.

[Kilmatead]

In which case you may simply replace $S (or $A) with @$> for your selections parameter and there will be no such limit as WinRAR will process the dumped listfile instead, poo-pooing any plebeian command line limits.

[Ross]

There is nothing wrong with those commands (I just created user-commands for all of them and they respond as expected) - so something else must be interfering with your pane selections.

Try substituting $A for $S, and see if it makes a difference (it passes the same selections, except $A adds full paths to each element, which should make no difference to WinRAR, but may to anything interfering with your selections).

I don't know why, because this used to work great. Replacing $S with $A didn't work, the effect just seemed the same when testing with

Code: Select all

Create RAR archive, asking for filename, and store in current folder (not oposing pane)
> rar.exe a -r -ep1 "$?.rar" $A

..so I'll assume it won't work with the other examples too.

If this happens with $A as well, then as a last test, try selecting your files and typing "$ $>" into the addressbar and hitting <Enter> - your selections should open in your default text editor. This is just a more immediate way of checking that all your selections were indeed "seen" by x2 without some gremlin snagging them.

No Gremlin snagged them! The whole selection opened in an output .txt file! Nothing wrong when it comes to $ $>! (without quotes). Why?

I suspect you may have some sort of "helper" programme installed which monitors keystrokes, or file-selections (from explorer) for shortcuts/additional menus? Anything like that sound familiar?

Yes, some things do sound familiar: I have AutoHotKey, it monitors keystrokes so it can expand abbreviations. But AutoHotKey is a legit, not keylogger program, and I use it since 2008, and it always played nice with x2. this problem is only a couple of weeks old. Still, I tried those commands with buttons pinned to the toolbar interface, with clicks, not keyboard shortcuts... the effect is the same!

If you select enough files you will run into the command line length limit (8191) even using $S which only sends the filenames.

Frizzle, this is not the case because I took only a very small # of files as sample.

In which case you may simply replace $S (or $A) with @$> for your selections parameter and there will be no such limit as WinRAR will process the dumped listfile instead, poo-pooing any plebeian command line limits.

That's news to me. Do I have to create manually a 'process list' to be parsed or something?

[Kilmatead]

Do I have to create manually a 'process list' to be parsed or something?

No, as stated, simply replace $S with @$> in the user-command definition. The "@"-sign prefix is WinRAR's command-line directive to open a listfile (a text file containing a list of object-paths on each line). The '$>' token is x2's means of outputting such a listfile (it's created in your temp folder as 'x2tmpList.txt', and that filename is automatically passed to the target programme as part of the argument). WinRAR will automatically start munching its way through the text file quite happily just as if you supplied the files as separate parameters. This is particularly useful when passing selections from a scrap-container, where the contents do not all share the same paths and $S would obviously fail miserably (which is why $A is more often the better choice, though as that supplies full paths as separate objects, the command-line character limit is used up quickly; using $> eliminates this, as technically you could send innumerable objects without penalty). Obviously this only works with utilities which are able to process listfiles - not all can, and not all in the same way ('@' is particular to WinRAR only).

Ironically this token is documented in the PDF manual (page 289), though it is still not included in the popup quick-reference of user-command tokens ("info" button). This makes even dozy kittens very sad, as it was one of this dozy kitten's better ideas in the first furry place.

Regarding your other anomaly, I suggested looking at any "tray" applications/helpers because sometimes they may accidentally send an extra code through the window buffer when detecting explorer-listviews which can interfere with the last "focused" object, possibly toggling it (how else to explain a single unpredictable missing object?). This is only a guess, as obviously the gremlin is local to your computer (you do seem to be having an unfortunate month of late regarding compu-stuff, aren't you? ).

When in doubt, deactivate everything in your tray menu and see if it still reoccurs (and I do mean everything - even things you "trust"). Using the @$> method in your user-commands "may" work, but that would only be masking whatever the underlying broader cause of the problem may be, not actually solving it.

[Ross]

When in doubt, deactivate everything in your tray menu and see if it still reoccurs (and I do mean everything - even things you "trust"). Using the @$> method in your user-commands "may" work, but that would only be masking whatever the underlying broader cause of the problem may be, not actually solving it.

So I did the exhaustive test. First I disabled everything from startup and rebooted. After loading Windows, I tried the commands. I did some tweaks in them, and I FINALLY got this WORKING output (there = opposing pane, here = current location).

Code: Select all

EXTRACT pack THERE
Alt+3
> "C:\Program Files\WinRAR\WinRAR.exe" x "$F" "$I"

EXTRACT pack HERE
ALT+5
> "C:\Program Files\WinRAR\WinRAR.exe" x "$F"

PACK in RAR, asking for name, THERE
CTRL+ALT+3
> "C:\Program Files\WinRAR\WinRAR.exe" a -r -ep1 "$I"\"$?" $S

PACK in RAR, asking for name, HERE
CTRL+ALT+2
> "C:\Program Files\WinRAR\WinRAR.exe" a -r -ep1 "$?.rar" $A

PACK in RAR, using current dirname, HERE
CTRL+ALT+6
> "C:\Program Files\WinRAR\WinRAR.exe" a -r -ep1 "$C" $S

PACK in RAR, using current dirname, THERE
CTRL+ALT+8
> "C:\Program Files\WinRAR\WinRAR.exe" a -r -ep1 "$I\$C.rar" $S

PACK in ZIP entire current folder, HERE
CTRL+ALT+7
> "C:\Program Files\WinRAR\WinRAR.exe" a -r -ep1 "$I\$C.zip" "$P\"

PACK single file in RAR, HERE
CTRL+ALT+4
> "C:\Program Files\WinRAR\WinRAR.exe" a -r -ep1 "$B.rar" $S

No, as stated, simply replace $S with @$> in the user-command definition. The "@"-sign prefix is WinRAR's command-line directive to open a listfile (a text file containing a list of object-paths on each line). The '$>' token is x2's means of outputting such a listfile (it's created in your temp folder as 'x2tmpList.txt', and that filename is automatically passed to the target programme as part of the argument). WinRAR will automatically start munching its way through the text file quite happily just as if you supplied the files as separate parameters. This is particularly useful when passing selections from a scrap-container, where the contents do not all share the same paths and $S would obviously fail miserably (which is why $A is more often the better choice, though as that supplies full paths as separate objects, the command-line character limit is used up quickly; using $> eliminates this, as technically you could send innumerable objects without penalty). Obviously this only works with utilities which are able to process listfiles - not all can, and not all in the same way ('@' is particular to WinRAR only).

Ironically this token is documented in the PDF manual (page 289), though it is still not included in the popup quick-reference of user-command tokens ("info" button). This makes even dozy kittens very sad, as it was one of this dozy kitten's better ideas in the first furry place.

Now I get it. I wasn't recognizing that "@" was about the filelist-processing capability WinRAR has.

Regarding your other anomaly, I suggested looking at any "tray" applications/helpers because sometimes they may accidentally send an extra code through the window buffer when detecting explorer-listviews which can interfere with the last "focused" object, possibly toggling it (how else to explain a single unpredictable missing object?). This is only a guess, as obviously the gremlin is local to your computer (you do seem to be having an unfortunate month of late regarding compu-stuff, aren't you? ).

Yes, and I finally reverted back from Windows 8.1 to 7 and couldn't be happier. I really don't understand why Windows 8 is so problematic. I gave it four chances in different seasons... couldn't make things work out in the end. But this also means that this PC is CLEAN. The only "new" thing here is that I'm back to Microsoft Security Essentials instead of Comodo Internet Security and I also gave Spybot 2.x a try when first installing Windows 7 - the traditional spyware remover has now a 'clean file list generator', which takes the system default files before any modification and creates a whitelist of them, so future scan procedures will take a shorter time.

So it created three services to run in the background, which I don't exactly know what they're for and don't know how harmful they are for performance: Spybot-S&D 2 Scanner Service, Spybot-S&D 2 Update service and Spybot-S&D 2 Security center service. Besides there is a Razer service called "Razer Overlay Subsustem Emergency Service", installed by Razer synapse (Mouse) and Apple Mobile device service. These are the non-Microsoft services running. (Oh, there is FileZilla server too, but I use it continuously for years).

Forgot to tell: besides the two AutoHotKey scripts, there is this VERY NICE application called "Everything" (Search Everything). Just finds files though all the computer without hog. So I guess you're not referring to this utility when you said "everything":

When in doubt, deactivate everything in your tray menu and see if it still reoccurs (and I do mean everything - even things you "trust"). Using the @$> method in your user-commands "may" work, but that would only be masking whatever the underlying broader cause of the problem may be, not actually solving it.

Bottomline: THANKS Kilmatead and x2 intellectual patrons!