user commands: examples and help

A collection of especially useful xplorer² topics and ideas. New users may find it helpful to look here before searching the other forums for information. >>>>>> Please post new material in the relevant forum. (New stuff posted here will be removed.) Thanks. -fg-

Moderators: fgagnon, nikos

DougalScott
Bronze Member
Bronze Member
Posts: 77
Joined: 2009 Apr 26, 01:52
Location: Townsville, Australia

Post by DougalScott » 2012 Jan 17, 01:11

For multiple commands from the address bar separate them with ampersand (&). eg

Code: Select all

$ dir "$L" & dir "$R"
to display a dir listing of the left pane and then the right pane (I know it is a bit redundant from a dual pane X2 :)). Something more useful is

Code: Select all

$ "C:\Program Files\7-Zip\7z.exe" a "$R\Backup.7z" $S && del $S
This first calls 7Zip to create an archive called backup in the right pane folder, and if successful it then deletes the files added to the archive. The double ampersand (&&) is important. Commands following a single & will always run, those following a double && will only run if the previous command did not generate an error. If using redirection the comand and redirection have to be wrapped in brackets. You can also group commands with brackets so the whole group only run if the previous one worked.
Putting that all together, the following will prompt the user for the archive filename (using X2 token $?), redirect the 7Zip command output to a log file, then (if 7Zip didn't error) report files archived and delete those files, and finally report done (regardless of 7Zip exit status).

Code: Select all

$ ("C:\Program Files\7-Zip\7z.exe" a "$R\$?.7z" $S > log.txt)  && (echo These files were archived: & echo $S & del $S) & echo Done!
|| is opposite of &&, it will run the following command if the previous command did error. I don't think there is anyway to combine && and || to get an if else type structure.
More info about these symbols is at http://ss64.com/nt/syntax-redirection.html.
Same can be used in user commands.

DougalScott
Bronze Member
Bronze Member
Posts: 77
Joined: 2009 Apr 26, 01:52
Location: Townsville, Australia

Post by DougalScott » 2012 Jan 17, 01:24

Kilmatead wrote:...except for some reason $N (or $F) retains the last selected file as an argument and passes it to ed2, even if that file is explicitly deselected before calling the user command.

This does not happen with $S, which behaves as expected - the deselected file is not passed, and ed2 opens empty, as it should.

Selecting/deselecting is done via the middle-mouse-button, under Vista.

This happens with notepad++ as well, so it isn't the application.

Is this supposed to happen, or am I missing something?
This isn't related to the "remember current session for next launch" setting in N++ is it?

Kilmatead
Platinum Member
Platinum Member
Posts: 4569
Joined: 2008 Sep 30, 06:52
Location: Dublin

Post by Kilmatead » 2012 Jan 17, 08:19

DougalScott wrote:This isn't related to the "remember current session for next launch" setting in N++ is it?
No, it's application agnostic - x2 just doesn't handle the singular-tokens correctly, placing way too much significance upon "focus" at the expense of the rights of starving children everywhere.  This has been a long-standing issue, and basically negates the practical usefulness of $F.   Since $A, $S or $> can just used instead (and behave as expected) it's not the end of the world, but it is a logical imbalance, especially where a particular filetype is expected for a given utility, and you accidentally send it something previously de-selected... which can't be rationalised, no matter how far one stretches human reasoning. :shrug:

DougalScott
Bronze Member
Bronze Member
Posts: 77
Joined: 2009 Apr 26, 01:52
Location: Townsville, Australia

Post by DougalScott » 2012 Jan 17, 22:59

Kilmatead wrote:No, it's application agnostic - x2 just doesn't handle the singular-tokens correctly, placing way too much significance upon "focus" at the expense of the rights of starving children everywhere.
Edit: was confusing $F and $A.

But aren't $N and $F supposed to return the current file, not the selected files? Otherwise why have N/F and S/A? $F seems consistent with $N, $B, $E, etc (the top 8 listed tokens) which all seem to relate to a single file,   which all just return info about the current file which seems reasonable.  :confused:
Or was your post in jest?  :)

Kilmatead
Platinum Member
Platinum Member
Posts: 4569
Joined: 2008 Sep 30, 06:52
Location: Dublin

Post by Kilmatead » 2012 Jan 18, 07:48

Returning the "current file" (as opposed to an obviously selected file) wouldn't make sense from a practical point of view in User Commands: as I imagine it, $F is just the "singular form" of $A, so (for example) if you have Notepad set as a toolbar button, using $F will open Notepad with (as you call it) the current file whether it is selected or not (!) - but say you want to just open an instance of Notepad to scribble a note to yourself?  You can't open a "blank" instance as x2 insists upon giving it a filename no matter what, so the best you can hope for is an error message which you can clear with a click.  Using $A on the other hand, you can click the toolbar-button and Notepad will open either empty (as expected, as no files are selected) or with whatever group you may have chosen - thus you have a choice.  The focussed pseudo-selection is irrelevant, as it should be.

I see this as an irrational inconsistency - all well and good calling something the "current file" (i.e., focussed) - but if it's not a selected file, what good is it?  Obviously (to me), if something isn't selected, that means I don't want to use it.  It's kind of the x2 equivalent of being forced to eat all the vegetables on your plate - even the yucky green ones.  

Try it yourself - select a file, then intentionally de-select it, then click on Notepad or something - does it seem logical to you to be force-fed something you just intentionally spit back out?

DougalScott
Bronze Member
Bronze Member
Posts: 77
Joined: 2009 Apr 26, 01:52
Location: Townsville, Australia

Post by DougalScott » 2012 Jan 18, 09:54

I imagine it differently. The singular form of $A is just $A with one file selected eg $A = selected file or files. Whereas $F is the current file (whether selected or not). If you want to be able to open an app with none, one or multiple docs, then use $A.

Using Notepad++ as an example when I invoke

Code: Select all

> notepad++.exe $A
with no file selected it happily gives me an empty document.

I can imagine utility in this distinction between $A (selected) and $F (focussed). For example

Code: Select all

$ move $A "$F"
to move the selected files/folders to the focused folder, or

Code: Select all

> 7z.exe a "$F" $A
to add the selected files to the focussed archive.

If you never want to be bedevilled by the focussed not selected item, then stick to $A and $S, and excommunicate $F and $N. The heretics amongst us can bask in our freedom to use the distinction between focussed and selected to achieve other ends. And everyone can rejoice at the wisdom of the maker in foreseeing all out needs. :)

Disclaimer: The commands above are for argument only and are not recommended as is. There is no check that the destination is not a file (can't remember exactly what copy will do, but definitely not nice), and although 7Zip should just give an error if the target isn't a zip archive it still could get messy.

Kilmatead
Platinum Member
Platinum Member
Posts: 4569
Joined: 2008 Sep 30, 06:52
Location: Dublin

Post by Kilmatead » 2012 Jan 18, 10:28

DougalScott wrote:If you never want to be bedevilled by the focussed not selected item, then stick to $A and $S, and excommunicate $F and $N. The heretics amongst us can bask in our freedom to use the distinction between focussed and selected to achieve other ends. And everyone can rejoice at the wisdom of the maker in foreseeing all out needs.
Speaking as one of the heretics :D, you'll note that I actually had to argue rather vehemently about a year and half ago for $A, $>, and $S to not supply the "focussed" object in the same way as $F does now - all the tokens used to behave the same, which was just silly.  And also points out how your assumption that $F is for $Focussed is not correct - it was always intended as the singular $A - to intentionally stop users from passing superfluous arguments to utilities that might baulk at such effrontery. :shrug:  Yes, that sounds ludicrous now, but remember in Nikos' mind it's still 2002 (back when he was free and single), so sometimes he doesn't realise the world has moved on a bit since. :wink:

That $F is the most commonly recommended token is one reason I keep harping on about this - newcomers have enough trouble getting out of bed in the morning, never mind dealing with largely undocumented functions (like the '$>' Token which STILL hasn't been added to the official list!).

DougalScott
Bronze Member
Bronze Member
Posts: 77
Joined: 2009 Apr 26, 01:52
Location: Townsville, Australia

Post by DougalScott » 2012 Jan 18, 10:57

Kilmatead wrote:Speaking as one of the heretics :D, you'll note that I actually had to argue rather vehemently about a year and half ago for $A, $>, and $S to not supply the "focussed" object in the same way as $F does now - all the tokens used to behave the same, which was just silly.  And also points out how your assumption that $F is for $Focussed is not correct - it was always intended as the singular $A - to intentionally stop users from passing superfluous arguments to utilities that might baulk at such effrontery. :shrug:  Yes, that sounds ludicrous now, but remember in Nikos' mind it's still 2002 (back when he was free and single), so sometimes he doesn't realise the world has moved on a bit since. :wink:

That $F is the most commonly recommended token is one reason I keep harping on about this - newcomers have enough trouble getting out of bed in the morning, never mind dealing with largely undocumented functions (like the '$>' Token which STILL hasn't been added to the official list!).
Actually I didn't assume it stood for $Focussed, I guessed it might stand for focussed/current $File (singular), like $Name, $Path and $All. But thank you for fighting the lunacy of including the current/focussed item in the selected group, that would have been just wrong.  :thumbup:

Now I must be gone to experiment and find out what $> does. :)

DougalScott
Bronze Member
Bronze Member
Posts: 77
Joined: 2009 Apr 26, 01:52
Location: Townsville, Australia

Post by DougalScott » 2012 Jan 18, 11:19

Interesting, creates x2tmpList.txt with selected (not those pesky focused) item paths in it. Maybe I can retire Alt+c, Ctrl+v? Then again with Alt+c, Ctrl+v I get to name the resultant file and select the folder for it rather than go hunting for it in my temp folder. I guess it might be useful as a batch precursor that does something else with the items in that file. Although not sure why you wouldn't just use $S in the command (probably my limited imagination).

Kilmatead
Platinum Member
Platinum Member
Posts: 4569
Joined: 2008 Sep 30, 06:52
Location: Dublin

Post by Kilmatead » 2012 Jan 18, 11:25

DougalScott wrote:Now I must be gone to experiment and find out what $> does.
Another one of my better ideas (hey, I'll take credit for anything - oh, wait - this was my idea!).  It sends the list of selected filenames to a temporary text file of CRLF-separated lines (otherwise known as a ListFile) which is created in the user's Temp folder - then that temporary filename is passed to a utility which can use ListFiles (like the popular IrfanView, as exampled here as a practical implementation - hmm - is "exampled" actually a verb?  Well, it is now :shrug:).

One of its primary benefits is that it can handle selections of "lots and lots of files" which would otherwise break the command-line limit which Windows imposes, where commands like $A and $S unexpectedly fail miserably.

For amusement, select a few files and type "$ $>" into the address-bar and watch what happens when you press <Enter> (yes, more undocumented tricks!)

DougalScott
Bronze Member
Bronze Member
Posts: 77
Joined: 2009 Apr 26, 01:52
Location: Townsville, Australia

Post by DougalScott » 2012 Jan 18, 11:34

Getting around the various cmd line length limits, I hadn't thought of that and very useful (told you my imagination was limited).

And $ $> just opens the temp file in the associated editor?

Kilmatead
Platinum Member
Platinum Member
Posts: 4569
Joined: 2008 Sep 30, 06:52
Location: Dublin

Post by Kilmatead » 2012 Jan 18, 12:22

DougalScott wrote:And $ $> just opens the temp file in the associated editor?
Basically yes - I never said it was exciting - but I thought of it when you said:
DougalScott wrote:rather than go hunting for it in my temp folder
The '$>' token is intended to be used with utilities that support listfiles (obviously) so there's never a need to "go hunting" yourself - the fullpath x2tmpList.txt filename is automatically passed to the called utility - no batches necessary.  For example, since you're already playing with one toy I made, you might as well play with another - this one supports the command-line argument /List= which would be used as

Modifiche.exe /Auto /Recurse /List="$>" /Log /Safe

Or something along those lines (you get the general gist).

DougalScott
Bronze Member
Bronze Member
Posts: 77
Joined: 2009 Apr 26, 01:52
Location: Townsville, Australia

Post by DougalScott » 2012 Jan 18, 12:46

Didn't mean to imply lack of utility, just my main use for listfile has been for historical reference, or to reuse in a batch file, so I want to put the file in an appropriate place with a relevant name, not so much use it as a listfile for a command on the fly. Other than that I only use listfiles for archive utilities, and they all take a larger selection of files than I have ever used.

But I think I may have a use for it to pass a set of files to a script that does something useful with them (like calculate hash values and add to the listfile).

Like all good tools, it doesn't matter if you have a use for it now, once you have it a use will arise (related to "to a hammer all problems look like nails"). :)

Kilmatead
Platinum Member
Platinum Member
Posts: 4569
Joined: 2008 Sep 30, 06:52
Location: Dublin

Post by Kilmatead » 2012 Jan 18, 13:02

DougalScott wrote:Like all good tools, it doesn't matter if you have a use for it now, once you have it a use will arise (related to "to a hammer all problems look like nails"). :)
You see?  That's probably why these things are all undocumented "features"... nobody ever looks at it from the Nail's point of view!  Everybody waltzes around like they're the big hammer in town, but it's always the little guys (the nails) that do the dirty work.  Anthropomorphically speaking, they take it personally when you put them in the same basket as "problems".  Problems, as any good Builder-Provider's (what the Americans call a "Hardware Store") will tell you, are always found on the second-isle to the left, near the back!

So, today is thusly dedicated to the unsung hero of file management, the humble and ever-undocumented $> token.  (Huzzah!)

(Who needs blogs when you can just make this stuff up as we go along?  Much more fun.)

Roman Sandstorm
New Member
Posts: 1
Joined: 2013 Feb 15, 11:06

Re: user commands: examples and help

Post by Roman Sandstorm » 2013 Feb 15, 11:14

profess wrote: This thread was originally posted  in the xplorer² Professional forum.        
Moved here 25-May-2010 =fg=
=====================================================


Hi everyone,

Is it possible for you to post some example user commands, with a brief explanation of what they do?  For example

$ mkdir "$B"

creates a folder with the same name as the selected file.  A document selected called "project 123.doc" would create a folder named "project 123".  

This was really a useful command, but like someone else mentioned, the console popping up is a real annoyance.

Luckily, there is an alternative option, and that is to use xcopy instead of mkdir. Xcopy can reproduce a source directory *without* copying the content files, hence...

>> xcopy C:\Windows\en-US "$B" /t /i /c

The source directory (in this case "C:\Windows\en-US") just needs to not be in the same path as your desired destination, and not have any subdirectories within it. I used the untouched one above for convenience.

This will also create multiple directories from file names, but.... there's no error checking. It is *simple*. Like me.

Oh... and a console 'flashes' up briefly, but then goes away.

Enjoy.

Post Reply