Using abbreviated executable names in command prompt - exe

I'm sure my question has been asked before, but this is a case of not knowing what words to use to search it up. I'm using a Windows 10 machine, running command prompt, and I want to know how to use abbreviated executable names. For example, in bash on a linux machine, I can type subl, which will bring up sublime text 2. But I have to type out the full executable name in order to do the same thing on command prompt. Is there a way to assign a variable of some sort, like foobar instead of foo_bar_1234_11235.exe every time I want to run an executable in command line?

Related

pywinauto (or others): to emulate Ctrl+A & Ctrl+X anywhere (not only on specified app)

I'm looking for a way to generate a ctrl+A (select all), and then ctrl+x in a python script. I know how to generate this in a specific app (pywinauto and other modules do that). But I'm looking for a way to send these keys in any apps (in any field of the active windows). I want to launch the python script containing these keys anywhere (the script will be launch using a key shortcut. Details below (1))
EDIT: I'm NOT trying to copy/past in the command windows (cf. the 2 last sentences). My script send the keys in the command windows, but that's the problem I'm trying to solve...
Using python pywinauto (or Ctypes or other modules)
I tried several propositions listed here with the same result.
I thought pywinauto could do it. Following pywinauto latest documentation I tried that:
open an (any) app containing a text field (that's the active windows)
place the cursor where you want to make the select all + cut/past
run the script bellow using an shortcut (so you won't leave the active windows)
from pywinauto.keyboard import SendKeys
SendKeys('^a^x')
Result
The code only print ^A^X in the python console. It doesn't do what it's suppose to do in the field of the active window (where I placed my cursor): it doesn't select all + cut the text.
Using autohotkey:
The only way I found to simulate a real crtl+A ctrl+C is by using autohotkey (it works but it's not a python solution):
save the code bellow in my AHK script: select_copy.ahk
Send, ^a
Send, ^x
create another AHK script called shortcut.ahk where you will specify a shortcut to launch select_copy.ahk (shortcut.ahk sould run constantly in windows background (2))
!^+G:: Run select_copy.ahk , C:\Users\Me\Desktop
(meaning: when I hit ctrl+alt+shift+G run the script select_copy.ahk)
result:
It works. when I call the ahk, it select/cut things in the active windows.
A combination of both did not work
I tried to launch the select_copy.ahk from within a python script (using subprocess.call) but I ended up with the same result than pywinauto (or Ctypes): it only prints ^A^X in the consol, but doesnt select&cut. So I'm wondering if python could really do what autohotkey does.
(1) What the script will do: I will launch the script (using a shortcut key) on one or another html editor, it will cut all the text, parse its source code, make some change put back the datas in the clipbboard, and past it. I'm only missing the first part (select all + cut) and the last part (past).
(2) It's not the big deal since shortcut.ahk contains also all my other ahk shortcuts and scripts.
Your AutoHotKey script should work, and does on my machine. However, I recommend that you just have one shortcut.ahk file containing the following:
!^+G::
Send, ^a
Send, ^x
Return
...and then put this in your python file:
subprocess.call("C:\\Path\\To\\AutoHotKey.exe /r C:\\Path\\To\\shortcut.ahk")
replacing the paths with wherever the AutoHotKey executable is, and wherever the shortcut.ahk file is.
Just as a side note: !^+G:: triggers on Alt+Shift+Ctrl+G, not Shift+Ctrl+G as you wrote in your question:
(meaning: when I hit ctrl+shift+G run the script select_copy.ahk)
EDIT: Also, from the phrase in the python console in your question it seems like you're trying to select all and then cut it in CMD. This will not work at all. Instead, if you want to simply clear the console, just use the command cls (Windows only; use clear in Linux). If you want to copy the entire console output and then clear it (i.e. cut) you're gonna need something different.

How can I find all the versions of a Unix program on a system?

This came up in coursework, and I'm stuck:
Many systems have more than one version of a utility program so that users can choose the one they want. Suggest a command to find all the versions of make on a system. What determines which one a user actually gets? How might a user override the defaults?
How would you do that?
How UNIX finds programs
Unix-like systems store their executable programs in various directories for historical reasons.
The directories that are searched when you want to run a command are stored in an environment variable called $PATH, separated by colons (:). To see its contents, type echo "$PATH" in a terminal window. On my system, that shows (split to avoid a long line)
/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:
/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
They're searched in that order. If I want to run make, the system will first check /usr/local/sbin/make (which doesn't exist), then /usr/local/bin/make (also non-existant), then /usr/bin/make (which does exist, so it runs that).
How to figure out which one would run
The program which can be used to look through $PATH to figure out what program would be chosen. Running which make on my system produces the output /usr/bin/make.
Conveniently, which has a -a flag to print all executables that match, not just the first one. (I found this by consulting its manual, by running man which.) So which -a java should tell you where all of the versions of java are.
Changing the defaults
If you like, you can change the contents of the $PATH variable, like you can change any environment variable: If I run PATH="$PATH:/home/anko/bin", the next time the system needs to find a program, it will check through all of what $PATH used to be, plus a directory called bin in my home directory if it couldn't find anything else.
I could also prepend the directory, to make it take precedence over anything else, by doing PATH="/home/anko/bin:$PATH".

How to automatically open prompts, ssh, and do things using a script?

I have to connect to a linux server from my own Ubuntu machine and operate directly on the server.
A dozen of folder names are listed in a LIST file. How to write sth. (like a bash script?) to carry out the following procedures?
for fold_name in LIST {
/******on my own Ubuntu*******/
-- open 2 new tabs of prompt terminal
-- run an ssh command in both
-- then input passwd and log in automatically in both
/******on the linux server*******/
-- cd to directory xxx/fold_name in both
-- run aaa.exe in 1st tab
-- vim sth in the 2nd tab
}
Once the loop of open-tab-login is solved, I guess the second part is routine as simple bash script except that I don't know how to specify between 2 tabs, either.
The point is I want all tabs in the same terminal. To this end, manually, I often Ctrl+Alt+T to create a prompt and Ctrl+Shift+T to open many tabs within it. And ssh...cd...... in each one. You see how annoying and cumbersome it is!
There are a few things you might like to research, which will get you a little closer.
You can run an ssh without a password, if you use an ssh key. Check out ssh-keygen, and the -i option in ssh.
Opening up tabs in gnome-terminal can be done via the method described here: Open a new tab in gnome-terminal using command line
You can run specific commands (e.g. aaa.exe) on a remote box over ssh, by including the command after the ssh: ssh user#remotehost aaa.exe.
If you want multiple commands, try enclosing them in quotes: ssh user#remotehost "cd /xxx; aaa.exe". Vim does not need to be in the directory in question in most cases: ssh user#remotehost vim /xxx/filename"
If you want to do something interactive (like vim), include the -t flag in ssh.
The tabs will be independent of each other - I'd probably run half of the command in one window, the other (e.g. runnning aaa.exe in one window, using one command, and the vim in another window, using another command, that I just happen to run at the same time. This way I can resize the windows, and arrange them relative to each other, and see both at once.
-- open 2 new tabs of prompt terminal
This depends on which desktop you're using. For gnome, gnome-terminal takes the -e option to specify the script to execute in the new terminal window. So, for something like this, you would execute gnome-terminal -e $script &, placing each instance of gnome-terminal in the background.
If you're using a different desktop, other terminal applications typically have a similar option. So, you'd point the terminal application to a script that's going to run in the terminal, and complete the rest of your task for you.
-- run an ssh command in both
-- then input passwd and log in automatically in both
This is going to be more complicated. The classical solution is the expect utility. There might be other similar tools that do similar things, but expect is pretty much the usual way these kinds of things have been done in the past. When it comes to trying to automate an interactive application, expect is really the only way to go. Unfortunately, expect uses a somewhat arkane syntax, that first-time users typically find confusing, and hard to understand. I grumble, every time I see no other alternative but to use expect to automate something, but this is pretty much the only option that's usually available.

Command which will succeed on both windows and linux, but gives a different result

This question is built over a previous question I asked
Determine OS from a single command line operation
I have a tool capable of executing a command on a remote system when I provide the host name.
The remote machine can be Windows or Linux.
After executing a command, I should be able to determine the OS from the result of the command.
The solution provided earlier was uname which prints "Linux" on linus OS and fails for windows.
It works great theoretically but the problem I have is that any failure of command crashes the tool since Windows returns non zero return code in this case.
So to get around this issue I have two options in front of me
Force windows command line to return 0 as the exit code irrespective
of the actual result. (This has to be done as part of the single
command I can execute on the windows system)
Find a command (like echo) which will succeed on both systems (but unlike echo which gives the same result, should help me identify the OS)
I am not sure if the first option is possible, but a solution to either of them would help
whoami
Linux - will provide the user you are logged on as
Windows - will provide host/username
I still think echo "$PATH" is the right idea here if you can base your decision on the output.
Since with a shell (bash, tcsh, ksh, etc.) on linux and cmd.exe or powershell on Windows you will get very different results.
With a linux/etc. shell you will get a path string.
With cmd.exe you will get "$PATH".
And with powershell you will get the empty string.
That empty string result is technically valid for linux/etc. since you can have an empty path there but you can work around that by using "${PATH:-linux}" instead which, for an empty (or unset) $PATH variable on in a sh-derived shell will get you linux and will still get you an empty string from powershell (though this fails for a csh derived shell it seems).

Executing an Expect script from different locations

I am trying to run my Expect script from two different locations and it will work with the following Expect executables referenced:
My linux home directory (#!/usr/bin/expect)
A clearcase view on another server (#!/clearlib/vobs/otherdir/bin/expect)
The problem is that I cannot run the script in both places unless I change the reference of the Expect executable location to the first line of the file.
How can I get the correct instance of the Expect executable for the corresponding directory?
If your path is correctly set on both servers, you could use /usr/bin/env:
#!/usr/bin/env expect
That would use the expect as found in the PATH (/usr/bin in one case, /clearlib/vobs/otherdir/bin in the other)
By instead using env as in the example, the interpreter is searched for and located at the time the script is run.
This makes the script more portable, but also increases the risk that the wrong interpreter is selected because it searches for a match in every directory on the executable search path.
It also suffers from the same problem in that the path to the env binary may also be different on a per-machine basis.
And if you have issue with setting the right PATH, then "/usr/bin/env questions regarding shebang line pecularities" can help.

Resources