aliases with parameters

[muellerto]

On Windows you have the problem that some applications are based on a so called Explorer integration. The effect is that these applications make important entries in the context menu of the Explorer which do then not call Explorer functionality but application functionality based upon the Explorer's selection. This saves them a lot of GUI stuff, the big disadvantage of that is that these applications make themselves dependent from the Explorer.

Prominent examples are TortoiseSvn and TortoiseGit which are a SVN/Git clients both based on Explorer integration. But indeed there's just an executable binary and the Explorer integration does nothing else than calling this binary again and again with a concrete set of parameters. No witchcraft at all. Works good outside the Explorer if you know what you do.

I configured this satisfactory using small shell script files, that's simple. But I tried to configure this also using aliases to have all in a few lines on the same place, having the principle in mind to select some files and then run an alias on sel to call such a TortoiseSvn action, or on some ELNs or on . which is also often needed.

So I tried to use sel in the alias:

clifmrc: alias Tr='executable sel'

$ s 1 2 3
$ Tr

Not good. sel seems not to be expanded and remains an unknown path for the called executable. So I tried to let the parameter list open in the alias in the hope that the defined alias and any given parameters from the command line are expanded and then glued together before execution:

clifmrc: alias Tr='c:/path/executable'

$ Tr sel

Does also not work. The alias is called without parameters. What I really would like is to specify numbered parameters in the alias:

clifmrc: alias Tr='c:/path/executable $1 $2'

$ Tr file1 file2

Or with ELNs:

$ Tr 2 4 7

Also sel should work in this case:

$ Tr sel

An implementation could be to call just sh with the expanded alias as a script and when the script contains numbered parameters sh is responsible to evaluate them.

[leo-arch]

Hi @muellerto!

$ alias Tr='c:/path/executable $1 $2'

This is not how you add an alias. Rather, open the config file and, in the aliases section, add this line:

alias Tr='c:/path/executable'

Parameters passed to the alias name will be passed to the aliased command.

EDIT: Haven't tried, but c:/path/executable will most likely not work (clifm only knows about Unix like absolute paths). You most likely need to invoke the binary alone (executable), which will be executed provided it is found in $PATH. Otherwise, it will fail.

[muellerto]

My initial post had several inadequacies. I fixed this there. Indeed I always had three aliases in my clifmrc and the executable I use has no explicit path at all, it's in the search path.

Currently my aliases use a one liner shell script:

clifmrc: alias Tr='Tr.sh'

With this I can indeed specify a parameter on the command line:

$ Tr 23

The invocation expands the alias, expands the parameter and calls then the script with that parameter. But I need a different script for every single alias.

[leo-arch]

The invocation expands the alias, expands the parameter and calls then the script with that parameter. But I need a different script for every single alias.

Could you expand on this? What is exactly the problem? What are you trying to achieve and why do you need different scripts?

[muellerto]

The question is: can I configure an alias which is based directly on an executable which gets parameter values from the command line before execution? The alias is surely not a problem:

clifmrc: alias X='executable -p -z'

But can this be called with ELNs as ...

$ X 2 5 17

... so that this results in an expanded command line like ...

executable -p -z real_file_name_1 real_file_name_2 real_file_name_3

Or can I have a selection ...

$ s 3 5 7

... and then call it with the selection like ...

$ X sel

... so that I get a resulting command line like ...

executable -p -z real_file_name_1 real_file_name_2 real_file_name_3

In my case the word sel came into my resulting final command line. My executable said sel is not a valid path, this can only happen when clifm didn't expand it before.

However, when I configure the alias to use a small shell script it's different. The script gets the parameters always very well, it receives also an expanded sel as separate parameter values as it should be.

Is there a difference in the parameter handling and expansion and the handling of sel between an alias based on an executable and an alias based on a shell script? Do you use a shell when the alias is based on an executable or do you start the executable directly?

[leo-arch]

Yes, you can have an executable (including shell scripts) plus option parameters in an alias and then enter the alias plus whatever you like, including file names and the sel keyword, of course.

My executable said sel is not a valid path, this can only happen when clifm didn't expand it before.

As far as I know, the only way for sel not to be expanded is if there are no selected files, in which case no expansion is possible and the sel keyword is left untouched.

I'll take a look at it however. What is the name of this executable? I'll try to reproduce this.

EDIT: Tried with three different aliases, one for an internal command, another one for an external command, and a third one for a script:

alias a_int='p'
alias a_ext='stat -t'
alias a_script='~/script.sh'

Then I executed the three aliases passing to them the sel keyword, a few ELNs, and a bookmark named mybm:

a_int sel 1-3 b:mybm
a_ext sel 1-3 b:mybm
a_script sel 1-3 b:mybm

Everything works as expected, provided the expansion can be made. If not (e.g. no selected files, no ELN 3, or no bookmark named mybm), the corresponding keyword remains untouched.

[muellerto]

Interesting.

Maybe I had no selection when sel was in my resulting path. But this is also rather unexpected because it always wrong - sel is a construction only clifm understands. I would think when sel or an ELN or a bookmark has no expansion the resulting value should be empty.

The name of my executable is TortoiseProc.exe. It's part of the TortoiseSVN (and probably also TortoiseGit) software. You can install TortoiseSVN using it's installer, reboot and then you have TortoiseSVN in the path. Then you can call

$ TortoiseSVN.exe /command:repobrowser /path:./

Note 1: The slashes for the parameters are mandatory, - or -- are not allowed. When you call this from sh you must qualify them as \/.
Note 2: The slash at the end is special. TortoiseSVN.exe doesn't accept . as a directory name, you must write ./ - this took me half an hour to find out ...

If you need an URL for a real SVN repository for playing around take this one: svn+ssh://muellerto@svn.savannah.nongnu.org/pdrx

I use now a single small shell script for all my TortoiseSVN commands. This is an acceptable solution in my eyes. This script became necessary because I can then also manipulate some parameters (the single dot gets the slash at the end, an empty parameter is replaced by a dot and so on).

[leo-arch]

I would think when sel or an ELN or a bookmark has no expansion the resulting value should be empty.

Though POSIXLY correct, this approach has a few drawbacks in the context of clifm:

1. In the case of ELN's, deleting the number from the list of words in case it doesn't desginate any file name in the list of files might hurt external commands, for example, chmod(1) or chown(1), both of which take numbers as parameters. Note that keeping a list of external commands taking numbers as parameters is not even an option: a home made script, which can be named whatever you like, can accept this kind of parameters.
2. If we cannot do this for ELN's, we shouldn't do it for other keywords, such as sel or b:NAME. Why? Consistency.
3. As I see it, keeping the unexpanded keyword is a clear indication that the expansion wasn't successful: both internal and external commands will take care of printing the corresponding diagnostic message: there is no such thing as 'sel', so that the user immediately knows there's a problem with the keyword (this is at least clearer than letting the command run without arguments).