After testing a while with the Cmd.cmd framework in python, I noticed a problem I don't know what to do about. Plus I believe to have this working some hours before (or I'm just crazy), so this is even more weird.
I have the following example code, tested on both Windows and Linux systems (so it's not a Windows problem), but tab completion simply doesn't work.
If I use the exact same code in Python 2 it does work on the Linux system (not on the Windows one though)
import cmd
class Shell ( cmd.Cmd ):
def do_test ( self, params ):
print( 'test: ' + params )
def do_exit ( self, params ):
return True
def do_quit ( self, params ):
return True
if __name__ == '__main__':
x = Shell()
x.cmdloop()
Do you know why this happens, or what I can do, to make tab completion possible?
It actually works for me on Linux on both Python 2 and 3. However, my python setup was compiled with readline support, which is required for it to be automatic per the cmd documentation. I suspect your Linux Python 3 wasn't compiled with it.
Unfortunately, readline is Unix-specific. See python tab completion in windows for a discussion of other options on Windows.
I got it to work on windows after I installed the pyreadline module from here https://pypi.python.org/pypi/pyreadline/2.0
On Mac there is the Stand-alone GNU readline module.
You can get it with pip install gnureadline.
It has been tested with Python 2.6, 2.7, 3.2 and 3.3.
Related
Context
We are using NSIS 3.05 with Unicode true (this is important later).
We need to check if a certain process is running, let's call it "processToFind.exe".
In order to do that, we have been using nsProcess Plugin, which is set up correctly, found and integrated just fine.
We include Plugins from our git repository like this:
!addincludedir "C:\pathToRepo\NSIS\Include"
!addplugindir "C:\pathToRepo\NSIS\Plugins"
where pathToRepo is of course a valid path. We also tried using the default Plugin Directories (NSIS-Dir\Plugins\x86-unicode) to no avail (see below).
Documentation says, nsProcess (v 1.6) does suppport unicode. That's why we chose to use it.
NSIS UNICODE support (just rename nsProcessW.dll into nsProcess.dll)
When setting Unicode false or leaving the setting out (so default is ansi), it is working fine, too. ( = running processes found, not running processes not found )
The Installer is 32 bit, we are running on 64 bit Windows 10 machines.
Code
${nsProcess::FindProcess} "procexp.exe" $R0
MessageBox MB_OK "procexp: [$R0]"
which is defined in nsProcess.nsh (provided by plugin, not own code)
!define nsProcess::FindProcess `!insertmacro nsProcess::FindProcess`
!macro nsProcess::FindProcess _FILE _ERR
nsProcess::_FindProcess /NOUNLOAD `${_FILE}`
Pop ${_ERR}
!macroend
Problem
When having set Unicode true , nsProcess will always return 603 ("Process was not currently running").
That's the same, regardless if we try to find 32-bit or 64-bit processes.
That would be expected for 64-bit processes (they cannot be found from 32-bit installers, which is ok for us).
But I do expect it to find 32-bit processes.
Alternatives already explored:
Going through the list found at Check whether your application is running ...
Processes Plugin : Seems outdated, only sourcecode found.
"FindProcess.nsh" : Naming collision, didn't work, neither. Same symptoms.
DDE Server / Win32 Sync / Registry: Not an option.
"tasklist" command: Same symptoms. When executed in cmd, it works but not from installer.
nsExec::ExecToStack '"%SystemRoot%\System32\tasklist" /NH /FI "IMAGENAME eq ${processName}" | "%SystemRoot%\System32\find" /I "${processName}"' always returns "error". (* it's clear now why, see edit below)
"FindProcDLL" Plugin : skipped because
As of NSIS 2.46 this plugin no longer works...
Seemingly related Stackoverflow Questions explored:
NSIS : NsProcess UnExpected Output
Solution was to remove Unicode=true, which I cannot do.
NSIS- FindProc always returns 1
Uses FindProcDLL
NSIS - check if process exists (nsProcess not working)
Error was "Plugin not found" , which we do not have.
I am sure, we are making some "stupid" mistake since I cannot bring myself to believing we are the only ones with that requirement. So, any hints, suggestions and alternatives that are not listed above (or corrections to the above) are welcomed.
Edit
We totally messed up the tasklist call. As #Anders pointed out in comment: nsExec does not support pipes and on top of that, the syntax was also messed up.
Does official example work for you? It works on my machine.
Try this:
0) Delete all nsProcess.dll files (in NSIS, in your include folders, everywhere)
1) Remove line !addplugindir "C:\pathToRepo\NSIS\Plugins" from your script to use plugins in NSIS directories
2) Copy file nsProcessW.dll into **c:\Program Files (x86)\NSIS\Plugins\x86-unicode**
3) Rename file c:\Program Files (x86)\NSIS\Plugins\x86-unicode\nsProcessW.dll -> nsProcess.dll
4) Compile your script with Unicode true
I believe there is some file mismatch. To understand NSIS plugins structure see NSIS - check if process exists (nsProcess not working) .
I'm still using ANSI because I'm using some other plugins that don't have a Unicode variant, so nsProcess works for me, and I'm not sure how to answer your main question.
However, re: the tasklist command alternative you listed, the syntax isn't quite right. You're missing a closing quote after "IMAGENAME eq ${processName}["] and an opening quote before ["]${processName}" in the pipe to find.exe.
Also FYI note that if you use %SystemRoot%\System32\, a 32-bit process will be redirected to C:\Windows\SysWOW64\, and some programs have no 32-bit equivalent (e.g., pnputil). In this case, it doesn't really matter, but in any event to get around this, you should use $WINDIR\SysNative instead. You can also use ${DisableX64FSRedirection} from x64.nsh, but there are apparently some potential pitfalls there.
EDIT: Ah yes, and there's the issue with pipe and ExecToStack mentioned by Anders in the comments to the original question, requiring the call to be prefixed with cmd.exe /C
I'm trying to test code that runs off user input in VS Code.
When I use 'prompt' I get:
ReferenceError: prompt is not defined
I googled that and found this page saying I need to use node.js - makes sense!
I tried the node.js example code here:
var readline = require('readline');
var rl = readline.createInterface({
input: process.stdin,
output: process.stdout
});
rl.question("What do you think of node.js? ", function(answer) {
// TODO: Log the answer in a database
console.log("Thank you for your valuable feedback:", answer);
rl.close();
});
When I run it in VS Code I can see the output in the terminal asking for the input:
[Running] node "C:\Users\jon_d\AppData\Local\Temp\tempCodeRunnerFile.javascript"
What do you think of node.js?
But I can see anyway to input a value in VS Code? Someone mentioned I need to use an external terminal - but I can't find any info on how to do that on a PC only OSX? Can someone explain how i use cmd for this?
Cheers,
Jon
Since Windows PCs don't have a real "terminal", a common solution is to use vscode with WSL (Windows Subsystem for Linux). This replicates the workspace of a linux machine in vscode - you have access to a real terminal (which is built into vscode) and this is where you would enter your user input.
I'm not sure if what you want to do is possible with only cmd/powershell, but since WSL is so common and convenient, I thought I'd put it out there.
On linux the following operation with getopt works fine:
TEMP=`getopt :mvfuhr:: --long "mask,verbose,force,unmask, help, remask::" -n 'test.sh' -- "$#"`
On Solaris, i am unable use the long arguments to process...
Though the this works:
TEMP=`getopt :mvfuhr:: "$#"`
Looks like the getopt bundled with the solaris is of an older version. How can i make it work like linux? or is there some setting that needs to be done to process long arguments?
Here is a clever (although currently with a minor bug) way to handle this issue:
Using getopts in bash shell script to get long and short command line options
Making my PHP Command line application support Linux and Windows. Currently it has this code below to work from command line on Linux/unix
How can I make it work on Windows? I lan on having a setting to determine if the sytem is Linux or Windows and using the correct commands based on that but I do not know how to make these function below work in Windows
exec() is a PHP function to run stuff through the command line
exec("rm -f $dest_file", $var);
exec("mv $quant_file {$this->tmp_path}/{$src_filename}-quant.png");
You could test which platform you're on using the PHP_OS constant and run commands accordingly.
I would, however, suggest that you use the PHP provided filesystem functions (if possible).
Here are some links:
http://www.php.net/manual/en/ref.filesystem.php
http://www.php.net/manual/en/ref.dir.php
The neovim API provides nvim_set_current_dir(), but apparently does not expose a way to query cwd. How can I go about doing this?
old question, but I couldn't find the answer, so...
here it is; :lua print(vim.fn.getcwd())
ps; if you're using lsp, you may want to put it on on_attach; vim.api.nvim_set_current_dir(client.config.root_dir)
There is a function in the regular Vim API that can be used for this:
getcwd()
It turns out that user12542635's answer is kind of correct, but it doesn't put the answer in the proper context of a python plugin, so I'll do so here. I suspect Rafael Quintela's answer is also correct, but I don't have a lua test environment set up, so I'll leave that to others to assess.
In the context of an nvim python remote plugin, the following code will execute pwd in the nvim process, gather its result, and return it to the plugin process, where we can then instruct the nvim process to echo it:
import pynvim
from pynvim.api.nvim import Nvim
from typing import List
#pynvim.plugin
class CwdPrinter:
def __init__(self, vim: Nvim) -> None:
self.vim = vim
#pynvim.function("PrintCwd")
def print_cwd(self, args: List) -> None:
cwd = self.vim.command_output("pwd")
self.vim.command(f"echo 'cwd: {cwd}'")
PrintCwd could then be called from nvim as :call PrintCwd(). This is obviously contrived; if one needed to print the current working directory, one should of course simply type :pwd, but it illustrates generally how to invoke remote vim commands in a plugin.