I try to run test under debugger as:
perl -d $(which prove) t/file.t
But this has no effect because each test is run as separate job.
I have found --exec option, but when I provide it I lost any option from .proverc file and command line
prove -Ithis/is/lost --exec 'perl -d' t/file.t
How to run tests by prove with additional options and do not lose those options which were provided at .proverc file and command line?
I do not want repeat myself and write:
prove --exec 'perl -d -Ilib -Ilocal/lib/perl5' t/file.t
While -Ilib and -Ilocal/lib/perl5 are both at .proverc file
You can repeat yourself once if you set the PERL5OPT environment variable.
export DBG_MODE='-d -Ilib -Ilocal/lib/perl5'
prove t/file1.t # regular use
PERL5OPT=$DBG_MODE prove t/file2.t # with debugger
or with an alias or bash function
alias proved='PERL5OPT="-d -Ilib -Ilocal/lib/perl5" prove'
Related
If I try to use Visual Studio Code (on macOS 10.15) to edit my crontab, it opens an empty file without the contents of my crontab.
$ VISUAL='code' crontab -e
crontab: no changes made to crontab
I didn't actually expect this to work (without -w) but include it for completeness. But when I add the -w it still fails.
$ VISUAL="code -w" crontab -e
crontab: code -w: No such file or directory
crontab: "code -w" exited with status 1
It occurred to me that there may be some weirdness with quoting, but neither single quotes nor the following fixed anything:
$ function codew() {
function> code -w "$1"
function> }
$ export VISUAL='codew'
$ crontab -e
The problem seems to be that the crontab's tempfile is not actually present. But how do I solve this? How can I use VS Code to edit crontabs?
Create a file touch ~/code-wait.sh:
#!/bin/bash
OPTS=""
if [[ "$1" == /tmp/* ]]; then
OPTS="-w"
fi
/usr/local/bin/code ${OPTS:-} -a "$#"
Make this file executable:
chmod 755 ~/code-wait.sh
Add to your .bashrc or .bash_profile or .zshrc:
export VISUAL=~/code-wait.sh
export EDITOR=~/code-wait.sh
Run command:
EDITOR='code' crontab -e
here the setting works for me.
.bashrc
## vscode
export VISUAL=/path/to/code-wait.sh
export EDITOR=/path/to/code-wait.sh
code-wait.sh
#!/bin/sh
code -w $*
That is quite a complex issue because there is no way to detect which tool calls the preferred editor. The TTY is the same and no environment variables can help.
Still, I was able to come up with a solution that enables the foreground mode (wait) for temporary files. IMHO, most if not all tools that use external editors and are waiting for them to save the file do use temporary files.
Full script is at https://github.com/ssbarnea/harem/blob/master/bin/edit but I will include here the main snippet:
#!/bin/bash
OPTS=""
if [[ "$1" == /tmp/* ]]; then
OPTS="-w"
fi
/usr/local/bin/code ${OPTS:-} -a "$#"
I am writing a perl script, and the objective is to kick start an xterm, follow by setenv, follow by invoke a tool that pre-installed in the system.
Here is my system call command in my perl script
system("xterm","-hold", "-e", "setenv ZI_LIBERTY_IGNORE_CONSTRUCT_FILES $RAW_RF_DIR/lib/lib2v/qcdc_ignore", "setenv HOME_0IN /p/hdk/rtl/cad/x86-64_linux26/mentor/questaCDC/V10.4g_5/linux_x86_64", "modpath -n 1 \$HOME_0IN/bin", "modpath -n 1 \$HOME_0IN/modeltech/bin", "/p/hdk/rtl/cad/x86-64_linux30/mentor/questaCDC/V10.4f_5/linux_x86_64/bin/qcdc -c -licq -do run.tcl");
xterm was able to start, however it stopped when executing the setenv, after that i tried with the new command by replacing the setenv with $ENV
system("xterm","-hold", "-e", "\$ENV{ZI_LIBERTY_IGNORE_CONSTRUCT_FILES} = \"$RAW_RF_DIR/lib/lib2v/qcdc_ignore\"", "setenv HOME_0IN /p/hdk/rtl/cad/x86-64_linux26/mentor/questaCDC/V10.4g_5/linux_x86_64", "modpath -n 1 \$HOME_0IN/bin", "modpath -n 1 \$HOME_0IN/modeltech/bin", "/p/hdk/rtl/cad/x86-64_linux30/mentor/questaCDC/V10.4f_5/linux_x86_64/bin/qcdc -c -licq -do run.tcl");
Here is the error message showing up in the new xterm (same for both approach)
Can't execvp $ENV{ZI_LIBERTY_IGNORE_CONSTRUCT_FILES} = "/nfs/fm/stod/stod4003/w.eew.100/rf_uprev_model_2020ww14p1//subIP/hip/MTLM_SA/RF.1//lib/lib2v/qcdc_ignore": No such file or directory
Please advise that how to make the series of operation works in the new xterm? Thanks!
-Eric-
The program run with -e must be a program, not a shell built-in like setenv. Off the top of my head, I can think of two solutions:
Set the environment variables before starting xterm. They would then be inherited by xterm.
Let the program run by xterm be a shell, and use that shell to set the environment variables and launch the tool. Something like this (untested):
system("xterm", "-e", "/bin/sh", "-c", "FOO=bar; FIE=fum; /run/my/program");
According to the man page I read, the following is the syntax of the -e option:
-e program [ arguments ... ]
It takes a path to a program, and optionally arguments to pass to that program. Specifically, it doesn't take a shell command. (It would be bad to accept a shell command without having the user specify for which shell!) That doesn't preclude one from running a shell command, though. This simply requires launching a shell, as the following does:
xterm -e sh -c shell_cmd
Solution:
my $script = <<'__EOS__';
export ZI_LIBERTY_IGNORE_CONSTRUCT_FILES="$RAW_RF_DIR/lib/lib2v/qcdc_ignore"
export HOME_0IN=/p/hdk/rtl/cad/x86-64_linux26/mentor/questaCDC/V10.4g_5/linux_x86_64
modpath -n 1 "$HOME_0IN/bin"
modpath -n 1 "$HOME_0IN/modeltech/bin"
/p/hdk/rtl/cad/x86-64_linux30/mentor/questaCDC/V10.4f_5/linux_x86_64/bin/qcdc -c -licq -do run.tcl
__EOS__
system("xterm", "-hold", "-e", "sh", "-c", $script)
Since a process normally passes a copy of its env vars to process it creates, you could also write the above as follows:
local $ENV{ZI_LIBERTY_IGNORE_CONSTRUCT_FILES} = "$ENV{RAW_RF_DIR}/lib/lib2v/qcdc_ignore";
local $ENV{HOME_0IN} = "/p/hdk/rtl/cad/x86-64_linux26/mentor/questaCDC/V10.4g_5/linux_x86_64";
my $script = <<'__EOS__';
modpath -n 1 "$HOME_0IN/bin"
modpath -n 1 "$HOME_0IN/modeltech/bin"
/p/hdk/rtl/cad/x86-64_linux30/mentor/questaCDC/V10.4f_5/linux_x86_64/bin/qcdc -c -licq -do run.tcl
__EOS__
system("xterm", "-hold", "-e", "sh", "-c", $script)
You can use csh similarly; I'm simply more familiar with sh.
Is it possible to run an external command in a perl script and preserve the color?
As a simple example, how would I run ls from a perl script and get colored output:
#! /usr/bin/perl
exec "ls";
When I run this, the output is all white, but I would like to preserve the colors, in this example for the directories and executables, etc...
It appears that ls doesn't automatically turn on colours in a subshell.
$ echo `ls`
# Output is uncoloured
We can work around that by using the --color command-line option.
$ echo `ls --color`
# Output is coloured
You can use a similar trick in a subshell that is invoked from Perl.
$ perl -e 'system "ls"'
# Output is uncoloured
$ perl -e 'system "ls --color"'
# Output is coloured.
I have a situation where I need to detect if a particular perl executable, /usr/goofy/bin/perl exists and if so use it to run the Perl script otherwise use /usr/bin/perl.
I have been struggling with this small POC script, called perlshebang.pl:
#!/bin/sh -e
perls="/usr/goofy/bin/perl /usr/bin/perl"
for pl_exec in $perls
do
if [ -x $pl_exec ]; then
exec "$pl_exec -w -S \"$0\" ${1+\"$#\"}"
fi
done
print "[$^X] Whoop!\n";
When I run this on a system that does not have /usr/goofy/bin/perl I get this error message:
./perlshebang.pl: 6: exec: /usr/bin/perl -w -S "./perlshebang.pl" : not found
And when I run it on a system that does have /usr/goofy/bin/perl I get a similuar error message:
./perlshebang.pl: line 6: /usr/goofy/bin/perl -w -S "./perlshebang.pl" : No such file or directory
I think I am close but cannot figure out why I am getting these error messages.
Thanks!
To answer your question, "Why am I getting these error messages?", the problem is your exec line:
exec "/path/to/cmd arg arg"
# This will attempt to execute a file named "cmd arg arg"
# (with spaces in name) in directory /path/to/
Contrast that with
exec /path/to/cmd arg arg
# This will attempt to execute a file named "cmd" in directory
# /path/to/, with arguments "arg" and "arg"
So, that is why the shell complains that it cannot find your executable. You don't have a file named perl -w -s "perlshebang.pl", neither under /usr/bin/ nor under /usr/goofy/bin/.
This sounds a little ugly to me if you are releasing software that uses this hack
If you have no other choice, then I suggest you make sure there is always a /usr/goofy/bin/perl, and use the shebang line
#!/usr/goofy/bin/perl
on all your scripts.
For those systems where you want to use the system perl, just make /usr/goofy/bin/perl a symlink to /usr/bin/perl
A co-worker of mine came up with this. I am not sure I fully understand it but it seems to work fine:
#!/bin/sh
#! -*-perl-*-
eval ' if test -x /usr/goofy/bin/perl ; then
exec /usr/goofy/bin/perl -x -S $0 ${1+"$#"};
elif test -x /usr/bin/perl ; then
exec /usr/bin/perl -x -S $0 ${1+"$#"};
fi '
if $running_under_some_shell;
use strict;
use warnings;
print "hello world\n"; # if $foo;
printf("running %s v(%vd)\n", $^X, $^V);
__END__
unpod like docs.
See http://perldoc.perl.org/perlrun.html
You can run the idea out of a Perl script running /usr/bin/perl. Use the shebang line with the 'goofy perl' in your script that should run. Then run the following wrapper, followed by the normal invocation of the script (its name and arguments).
#!/usr/bin/perl
exec "#ARGV";
exec "/usr/bin/perl #ARGV";
print STDERR "Couldn't execute either.\n";
Let's call the above pick_perl.pl, and your script is script.pl. Run it all as
pick_perl.pl script.pl args-for-script
The exec replaces the running program altogether with the one it executes, ie. it loads the new program. Thus your script runs with its own shebang. If that failes exec returns quietly (with false) and the next statement is executed so the other Perl runs the script (overriding the shebang). This happens if script's shebang fails, but also if the first exec fails to execute for any reason.
If you wish/need to run checks then put exec in a full if block. One can also interrogate the 'goofy_perl' file further if -e isn't assuring enough.
#!/usr/bin/perl
$system_perl = "/usr/bin/perl";
$goofy_perl = "/usr/goofy/bin/perl";
# Your 'goofy_perl' script with its arguments
#script_cmd = #ARGV;
if (-x $goofy_perl) { exec "#script_cmd" }
exec "$system_perl #script_cmd";
The #script_cmd has the full command line for your script (which has 'goofy_perl' shebang).
Can sh itself check if a program exists or is in path?
I.e., not with the help of the "which" program.
I don't believe sh can directly. But perhaps something like:
which() {
save_IFS=$IFS
IFS=:
for d in $PATH; do
test -x $d/$1 && echo $d/$1
done
IFS=$save_IFS
}
and here's a nice variation that uses a subshell so that restoring IFS is not necessary:
which() (
IFS=:
for d in $PATH; do
test -x $d/$1 && echo $d/$1
done
)
Also, (in bash) if the command has been executed in the past and bash has already done the PATH search, you can see what it found with hash -t.
bash-3.2$ hash -t which
bash: hash: which: not found
bash-3.2$ which foo
bash-3.2$ hash -t which
/usr/bin/which
The utility command -v $CMD is apparently a portable option (in the sense of being part of POSIX); see also the very similar (though bash-specific) question, in particular this answer.