I need to check the exit status of a piped command from R on Debian, like here, but cannot make run echo "${pipestatus[1]}" successfully from R using system2/system function. The command works properly when I use command line.
The command I am trying to use in R can look like this (the shell I use is zsh):
system2("false", args = "|true;echo '${pipestatus[1]}'")
After some testing I can see that the exit status checking command cannot be quoted properly but I cannot figure out the correct way to do so.
Am I right that quoting this command properly is the issue? How to run this (echo "${pipestatus[1]}") command from R? Are there any alternatives to using the command in question to check exit status?
You can’t use zsh features here, since system2 doesn’t invoke a shell.
Instead, you’ll either need to use a raw system call or, better, explicitly invoke the shell in system2. You’ll also need to use double quotes instead of single quotes around ${pipestatus[1]} to allow expansion — otherwise zsh will interpret it as a literal string.
system2('zsh', c('-c', shQuote('false|true; echo "${pipestatus[1]}"')))
Related
I'm confused when i should use awful.spawn and when to use awful.spawn.with_shell. To me these look and work the same.
The only difference I see is that in awful.spawn you can set client rules and make a callback.
I would appreciate any examples or rules on when to use each one.
awful.spawn.with_shell really does not do more than spawning the given command with a shell: https://github.com/awesomeWM/awesome/blob/c539e0e4350a42f813952fc28dd8490f42d934b3/lib/awful/spawn.lua#L370-L371
function spawn.with_shell(cmd)
if cmd and cmd ~= "" then
cmd = { util.shell, "-c", cmd }
return capi.awesome.spawn(cmd, false)
end
end
So, why would one want that? Some things are done by shells. For example, output redirections (echo hi > some_file), command sequences (echo 1; echo 2) or pipes (echo hello | grep ell) are all done by a shell. None of these work when starting a process correctly.
Why would one not want a shell? For example, argument escaping is way more complicated when a shell is involved. When you e.g. want to start print a pipe symbol (no idea why one would need that), then awful.spawn({"echo", "|"}) just works, while with a shell you need to escape the pipe symbol the appropriate number of times. I guess that awful.spawn.with_shell("echo \\\|") would work, but I am not sure and this is the point.
Also, a shell that does nothing is an extra process and is a tiny bit slower than without a shell, but this difference is really unimportant.
I'm confused about this code! Why # cant't play a role that takes the length of a string?
string="abcd"
!echo ${#string}
In fact, the code behind # has become commented and cannot be executed!
Any advice?
This works correctly, but you cannot mix python and bash variables in this way. Try this instead:
!string="abcd" && echo ${#string}
The two statements have to be on the same line because in IPython, each ! statement opens a temporary subshell and variables are not persisted between shells. If you want to use multiline bash programs, you can use the %%bash cell magic instead:
%%bash
string="abcd"
echo ${#string}
I am trying to use environment variables set by ksh and the expect command in the same script. However, if I try to source both of them, it doesnt work. Is there a way to source ksh and expect in the same script?
Do something like
#!/usr/bin/ksh
. /path/to/ksh_stuff.sh
export FOO=bar
# other ksh stuff
expect <<'END_EXPECT'
source /path/to/expect_stuff.exp
send_user "FOO is $env(FOO)\n"
# other expect stuff
END_EXPECT
Adding quotes around the here-doc terminator (<<'END_EXPECT') means that the entire here-doc is single quoted, so ksh will not attempt any parameter substitutions on it. This is a effective way to isolate the expect script's variables from ksh.
In Korn shell you dot in the other script, example:
. ${other_script}
This will run in the same process as the parent script. The other script can see any variables that are defined in the parent script. If you want to sub-shell (to run an external command), then you will need to export any variables first.
If you want to reference environment variables in your expect script, (those that are exported by a ksh script that runs expect in a subshell) then your expect script needs to reference a global array env . For example if your ksh script exports MYPATH variable then subshells to expect, the expect might reference $env(MYPATH)
This question is about configuring the R console to behave like a bash shell when it comes to navigating the command history. It is somewhat related to the ?history. For brace-enclosed multi-lines, I'd like to configure the command history navigation of R to be similar to bash.
Presently when running R in an xterm under Linux, using the up-arrow to navigate the command history causes each previous line to be recalled one by one, even if a set of lines had been enclosed in braces. This occurs, for example, when copy/pasting a multi-line function from a text editor into the R console. Not so with bash.
Here is an example of how bash functions in this regard:
In a bash shell within an xterm under Linux, after typing the following five lines...
a=1
{
x=1
y=1
}
... the first press of the up-arrow will recall a single line reformulation of the brace-enclosed commands, like this ...
{ x=1; y=1; }
... and the second press will recall this ...
a=1
It seems that in R, the up-arrow navigates backwards one line at a time, regardless of encapsulation. Is there a way to configure R so that it's command history navigation functions like bash's?
You could use rlwrap. I use it for other console programs and it works very well. You will need to prepend the R command with the rlwrap binary and then your history lines can be restored in a number of ways, including multi-line matching.
Workaround for Linux/Unix
Similarly as in Rstudio (thanks to Ari B. Friedman comment), where user in R console is using ShiftEnter to bypass RETURN, you can start newline (in R terminal) without accepting newline command using Ctrl-VCtrl-J. This way the multi-line command will be accepted into history as one-liner with line-feeds instead of enters and you will even have the chance to edit it. You can even manage in your .inputrc file to have custom combination for this action.
I do not think direct reconfiguration of R is possible.
Readline man page may help more.
For example,
I executed "pwd" and it shows the current working directory. Then if I want to reuse that result in my another command, it would convenient to get it via a Unix command or built-in variable. Does it exist?
You can get the result, as in return code, using $?. In order to get the output you'll need to explicitly keep it around - e.g. with:
MYVAR=`pwd`
echo $MYVAR
Use $? inorder to get the status of the last executed command. Its value will be zero if the last executed command was successful else non zero.
The internal variable $? holds the return value of the last executed command or program. Example: http://tldp.org/LDP/abs/html/complexfunct.html#MAX.
If you don't need to run one command first, you can also try using pipes | to connect commands. I am constantly piping long directory listings over to more, so I can page through the results, with
ls -al | more
so if you want to use the results of running pwd as input to another program, you can try something like piping the results of pwd over to more with
pwd|more