Hello all I have come around a limitation of QProcess. If I use '|' then it skips the process but I need that '|' character in my process
Suppose I have a exe and I need '|' in its arguments list then it doesn't work because command prompt takes '|' as OR. and therefore it skips the preceding part.
e.g: myfile.exe arguments1 | arguments2
Now in above code you can see the '|' the arguments which separates the two arguments and is required by myfile.exe to perform the operation but due to '|' character it skips the part before that and it gives me output as
'arguments2' is not recognized as internal or external, operable program or batch file
How do I overcome this weird situation? I need '|' in my arguments list but process recognizes it as a OR.
Let me tell you guys the actual sitation. I am trying to extract a .cpio.gz archive using
gzip -d -c myarchive.cpio.gz | cpio -i
but due to | in the arguments I get output as
'cpio' is not recognized as internal or external, operable program or batch file
but if I run the ported linux binary of gzip in ubuntu then it works exactly as i wanted because the linux terminal doesn't recognizes | as OR
Please I need help
Thank you
QProcess is doing what you want it to do: pass the whole line of command to the shell. The problem is you either don't have the second program cpio installed or it's not in the PATH environment of your Qt executable.
Does that line of command work when you enter it in (I assume) Windows command prompt?
BTW. The vertical bar character is a pipeline, not an argument to the .exe. That line of command actually invokes 2 separate programs.
Related
To start from the beginning, I'm using ansible to open a Jar file in a linux environment.
Basically I do: java -jar someJarFile.jar, and it opens in command line.
Now, it prompts me with several questions which can be passed by hitting Return multiple times.
Finally the jar will produce a WAR file...
Here's where I need your help.
I want to use ansible to call an expect script so that it can automatically execute the jar and continuously hit enter until the jar is successfully completed/installed.
try
yes "" | java -jar someJarFile.jar
If you know the number of times you need to press <Enter> you can use echo -e '\n'. For example, if you know you'll need three <Enter>s:
echo -e '\n\n\n' | java -jar someJarFile.jar
This is also helpful for times when you need to input specific and distinct values which yes doesn't allow. For example, answering a prompt like:
Enter value [default]: <enter>
Enter number: 30<enter>
Ok?: y<enter>
Do the dangerous: n<enter>
Could be simulated by
echo -e '\n30\ny\nn\n' | java -jar someJarFile.jar
Consider following:
$ cd /home/mydir
$ jupyter notebook --port=8888
In plain English, I am running jupyter server from /home/mydir directory.
Is there a simple way to get this directory from within a notebook regardless if it's a R notebook or a Python notebook or whatever? Maybe there is some magic command or variable?
NOTE: getwd() is not an answer as it returns directory of a current notebook but not the jupyter server root.
I have a similar problem and found your post, although I don't see a viable solution yet. Eventually I did found a solution, although it works only because I only care about Linux and I only care about Python. The solution is this magic line:
J_ROOT = os.readlink('/proc/%s/cwd' % os.environ['JPY_PARENT_PID'])
(I put it in a module in my PYTHONPATH so that I can easily use it in any Python notebook.) See if it is good for you.
Remember that your iPtyhon is just a Python module, so you can execute any valid Python code in a cell. So, if you started your notebook and haven't executed any directory changes in your code, you should be able to retrieve your cwd with the following in a cell:
import os
os.getcwd()
But furthermore, you can execute shell commands in cells, so you can retrieve other information in the cell. For example:
!which jupyter
should give you the path to your jupyter executable.
Which then leads you to running something like:
!jupyter --paths
which should give you something similar to:
config:
/Users/yourdir/.jupyter
/usr/local/etc/jupyter
/etc/jupyter
data:
/Users/yourdir/Library/Jupyter
/usr/local/share/jupyter
/usr/share/jupyter
runtime:
/Users/yourdir/Library/Jupyter/runtime
Frankly I'm surprised that all this time later there is still no built-in way to do this. I have used Isaac To's solution on Linux but recently had to make a jupyter notebook portable to Windows as well. Simply using os.getcwd() is fragile because a cell using it to set your JUPYTER_ROOT_DIRECTORY can potentially be called again, after you have changed your working directory.
Here is what I came up with:
try:
JUPYTER_ROOT_DIRECTORY
except NameError:
JUPYTER_ROOT_DIRECTORY = os.getcwd()
I put it in one of the first couple cells with the initial import statements. If the cell gets called again, it will not re-set the variable value because the variable exists and does not throw an exception.
It should be noted that unlike Isaac To's solution it sets the value to the directory the current .ipynb was run from, which is not necessarily the same directory as the top-level dir the user can access in the left hand file pane.
My suggestion is to use an intuitive approach.
Create a new folder within the Jupyter environment with a very unique name, for example, T246813579.
You can now locate the Jupyter working path by searching in your file explorer. For example, you can use the Windows Explorer in order to locate your new folder.
The expected result should look something like this:
C:\Users\my_user_name\JupyterHome\T246813579
The answer from #Isaac works well for Linux, but not all systems have /proc. For a solution that works on macOS and Linux, we can use shell commands, taking advantage of the ! shell assignment syntax in Jupyter:
import os
JPY_ROOT = ! lsof -a -p {os.environ['JPY_PARENT_PID']} -d cwd -F n | tail -1 | cut -c 2-
JPY_ROOT = JPY_ROOT[0]
print(JPY_ROOT) # prints Jupyter's dir
Explanation:
Get the process ID (pid) of the current jupyter instance with os.environ['JPY_PARENT_PID']
Call lsof to list the process's open files, keeping only the current working dir (cwd)
Parse the output of lsof using tail and cut to keep just the directory name we want
The ! command returns a list, here having only one element
Alternate Version
To save the os import, we could also use shell commands to get the PID. We could also do the subsequent string wrangling in python, rather than calling tail and cut from the shell, as:
JPY_ROOT = ! lsof -a -p $(printenv | grep JPY_PARENT_PID | cut -d '=' -f 2) -d cwd -F n
JPY_ROOT = JPY_ROOT[2][1:]
In windows 7 at run prompt, this command succeeds in launching the .exe with the the optional input file "test2.dat"
c:/Program Files (x86)/IEUBKwin1_1 Build11/IEUBKwin32.exe k:/Project/EPA.Pb.IEUBK/batch.io/input/test2.dat
I want to do the same thing from within R.
In R, this command succeeds in launching the same .exe
shell.exec("c:/Program Files (x86)/IEUBKwin1_1 Build11/IEUBKwin32.exe")
But I've been unable to find a solution within R that will launch the .exe with the optional input file. I've looked at shell(), shell.exec() and system() but I could not find the right incantation that will pass the optional input file to the .exe.
Any thoughts?
Typing into the normal cmd.exe-promt a command including spaces as in C:\Program Files (x86)\... does not work:
The Command "C:\Program" could not be found.
Typing in the same command with double quotes does work. E.g.:
"C:\Program Files (x86)\7-Zip\7z" -a ...
To get it to work in R, you can use single quotes (') to mark a R string and double quotes (") for the command itself. Actually, you have the possibility of three different quotes to use (backtick is the third one `, see here for more information). Or you use escapes as mentioned in the answer of #Frank.
system('"C:/Program Files (x86)/IEUBKwin1_1 Build11/IEUBKwin32.exe" k:/Project/EPA.Pb.IEUBK/batch.io/input/test2.dat')
In addition ?system mentions not just to use shell in windows but also system2 as alternative:
...This means that it cannot be assumed that redirection or piping will work in system (redirection sometimes does, but we have seen cases where it stopped working after a Windows security patch), and system2 (or shell) must be used on Windows.
But for me system works totally fine not using piping or redirection.
shell.exec() is used for opening files associated in your OS.
in your case, the shell command should be preferred but you need to take care of spaces in your filenames and mask quotaion marks.
Please try:
shell("\"c:/Program Files (x86)/IEUBKwin1_1 Build11/IEUBKwin32.exe\" k:/Project/EPA.Pb.IEUBK/batch.io/input/test2.dat")
I am executing a ksh script named abs.ksh located at /app/fao.... which connects to a server,
But the server is receiving a script named "ksh" which is present in /usr/bin...
I am not calling any script called ksh in abs.ksh(sorry cannot paste the code).
Also this happens only when the script is run in debug mode.
In non debug mode it works fine.
Can anyone give me a hint of what might be happening here.
In a standard "classic" Unix environment there may be multiple shells. E.g. 'sh' the original Bourne shell, 'ksh' - the Korn shell, csh - the C shell, bash, tcsh etc. etc.. A user login will have the default shell set per login.
The #! at the start of an executable script is an instruction to interpret & run the subsequent text with the name of the program following the '#!'.
E.g. run this with perl
#!/bin/perl
<.. perl stuff ..>
So yes #!/usr/bin/ksh - will run the script with the command interpreter (shell) at that location.
Need more info. wrt how you run in debug mode. I.e. are you typing 'ksh -x ...' or 'sh -x' - if so where is that on your search path. E.g. 'whence ksh' - maybe you're running with a different shell in debug mode.
Also which os is this ?
as an replacement for ksh under cygwin, pdksh might be the only choice. but look like there have a bug for cygwin : pdksh(5.2.14-3) to support backslash path (\).
it will swallow the \ :
$ cd .\access
pdksh: cd: /cygdrive/e/.access - No such file or directory
After search on the internet, the same problem solved for other platform. but no idea how to solve it for cygwin.
Pdksh, like all Cygwin programs, does support backslashes as directory separators. But you have to quote them properly. Running shell scripts under Cygwin really teaches you to quote things properly, in particular to always put variable substitutions in double quotes, and not use echo carelessly (printf "%s" "$x" is portable and reliable: unlike echo, there's no risk that it might do backslash expansion).
Note that pdksh's compatibility with even ksh88 is far from perfect, so some scripts may fail for other reasons (such as relying on the status code of writer | reader being that of reader, which is the case in true ksh but not in pdksh). Cygwin includes zsh, which after you run emulate ksh is mostly compatible with ksh88 (though still not perfect).
There are non-Cygwin ports of ksh for Windows, including InterixSFUSUA and ATT's own port.
You have to use forward slashes, or double all the backslashes, or single-quote every string that might be a pathname. Sorry, there's no way around this. This is a general problem with trying to use Unix shells, for which \ is an escape character, on Windows.
From the Cygwin User's Guide:
Note
The usage of Win32 paths, though possible, is deprecated, since it circumvents important internal path handling mechanisms. See the section called “Using native Win32 paths” and the section called “Using the Win32 file API in Cygwin applications” for more information.
There is a utility called cygpath that is designed to be used in shell scripts that converts each way between Win32 and POSIX paths.
Here's a workaround for the problem. Start using bash and make the following modifications in config files.
Open ~/.bashrc
Add the following code at the end
wcd()
{
cd $(echo "$#" | sed 's/\\/\\\\/g')
}
Save it
Reload bash terminal.
Type
wcd ".\access"
along with the quotes and voila, you have your own windows compatible cd command.