The following CoffeeScript cakefile doesn't show any output:
{exec} = require 'child_process'
task 'watch', 'watch current directory and corrects the map file', (cb)->
console.log 'hello world'
exec 'coffee -w -b -m -c .' ,(err,stdout,stderr) ->
console.log err
console.log stdout
throw err if err
console.log stdout + stderr
It is compiling all the files but when I make error in the coffee file, it doesn't throw an error nor does it show anything about the compile files. But the exec command, when tried separately, does show the error.
Try spawn instead of exec. My guess is exec is expecting a buffer but coffee is giving a stream.
Related
command:
pp -o test -A addlist.txt test1.pl
content in addlist.txt:
lib_3.pm
lib
there are lib_1.pm and lib_2.pm under folder lib
test1.pl call functions defined in lib_1.pm and lib_2.pm and lib_3.pm
after I run the command above, I get error:
for packingin/pp: cannot find file or directory lib_3.pm
for packingin/pp: cannot find file or directory lib
Although I get the error, the output file from pp can print correct output. Who can tell me why?
I get help from githut.
The error is because the end of line of addlist.txt is windows. When I save the addlist.txt as Unix/Linux end of line, the error gong.
I have a case where I invoke the Perl debugger twice. For example, progA.pl:
use warnings;
use strict;
system("perl -d progB.pl");
and progB.pl:
use warnings;
use strict;
$DB::single=1;
print "Hello\n";
Then I run progA.pl like:
$ perl -d progA.pl
This does not work very well. On my system (Ubuntu 14.04, and Perl version 5.18), I get some errors from the debugger. For example:
### Forked, but do not know how to create a new TTY. ######### Since two debuggers fight for the same TTY, input is severely
entangled.
I know how to switch the output to a different window in xterms,
OS/2 consoles, and Mac OS X Terminal.app only. For a manual switch,
put the name of the created TTY in $DB::fork_TTY, or define a
function DB::get_fork_TTY() returning this.
On UNIX-like systems one can get the name of a TTY for the given
window by typing tty, and disconnect the shell from TTY by sleep
1000000.
It also tries to open a new terminal window, with title Dauther Perl debugger but the new terminal only show the error sh: 1: 3: Bad file descriptor.
How can these problems be avoided? I just want the debugger to work as normal.
Use 'do' instead of 'system'
perl -d progA.pl
# will stop after your $DB::single = 1
# line in progB.pl
perldoc -f do
do EXPR Uses the value of EXPR as a filename and executes the contents
of the file as a Perl script.
do 'stat.pl';
is just like
eval `cat stat.pl`;
I'm not sure if this is what you are looking for, because I don't understand the bigger picture of what you are trying to do.
But if you use a different debugger like Devel::Trepan at the outset, then things may work:
$ trepan.pl progA.pl
-- main::(progA.pl:4 #0x21282c8)
system("perl -d progB.pl");
(trepanpl): s
-- main::(progB.pl:3 #0x7042a8)
$DB::single=1;
(trepanpl): s
-- main::(progB.pl:4 #0x878be8)
print "Hello\n";
(trepanpl): s
Hello
Debugged program terminated. Use 'q' to quit or 'R' to restart.
(trepanpl): quit
trepan.pl: That's all, folks...
Debugged program terminated. Use 'q' to quit or 'R' to restart
(trepanpl) quit
trepan.pl: That's all, folks...
The (trepanpl) prompt after the "program terminated" message is a bit odd. But all it means here is that progB.pl is finished. After quitting that, as I did above, if you had another Perl statement after your system() command, then debugger show that rather give the second "finished" message.
Another feature of Devel::Trepan is that you can do nested debugging from inside that debugger with its debug command. Here is an example of that:
trepan.pl progA.pl
-- main::(progA.pl:4 #0x10612c8)
system("perl -d progB.pl");
set auto eval is on.
(trepanpl): debug system("perl -d progB.pl")
-- main::((eval 1437)[/usr/local/share/perl/5.18.2/Devel/Trepan/DB/../../../Devel/Trepan/DB/Eval.pm:129] remapped /tmp/HSXy.pl:6 #0x51f13e0)
system("perl -d progB.pl")
((trepanpl)): s
-- main::(progB.pl:3 #0x9382a8)
$DB::single=1;
(trepanpl): s
-- main::(progB.pl:4 #0xaacbe8)
print "Hello\n";
(trepanpl): s
Hello
Debugged program terminated. Use 'q' to quit or 'R' to restart.
(trepanpl): quit
trepan.pl: That's all, folks...
$DB::D[0] = 0
Leaving nested debug level 1
-- main::(progA.pl:4 #0x10612c8)
system("perl -d progB.pl");
(trepanpl):
I have a perl script which returns value "return 1;" or "return 0;".I tried also "exit 1;" and "exit 0;"
In my makefile I have the following code:
ifneq ($(TRG_TYPE),node)
VAR := $(shell perl $(ROOT)/Make/chipdep.pl $(ROOT) $(CHIP) $(NAME) )
ifeq ($(VAR),1)
$(error just a test error. Aborting)
endif
endif
I know that perl script works - I tested it separately, but I never see this error and abort, even when it should be seen!
The value of a shell invocation is the output of the shell command, not its exit code. Make your script print 0 or print 1, or in the general case, do $(shell yourcmd >/dev/null 2>&1; echo $$?) to obtain just the exit code from a shell command.
This seems slightly backwards, though. If your script returns 0 for success and 1 for failure, maybe you should simply run it as the first command of your target; the target will abort if any of its commands fail.
I am importing a file into SQL Server using BCP utility in Perl program.
In the file which I am importing, there is a wrong date format so the Import process fails with following error:
SQLState = 22008, NativeError = 0
Error = [Microsoft][SQL Server Native Client 10.0]Invalid date format
I am executing the bcp command as follows in my perl program.
my $myBcp = "bcp.exe" <table name> in <temp file path> -f<format file> -m 1 -h "FIRE_TRIGGERS" -o<log file path>
my $myResult = system($myBcp);
When I print $myResult it gives me '0'. Since there is an "Invalid date format" error, it should return me a error code.
Can anyone let me know how to catch Invalid Date Format error in my perl program?
Thanks
system() simply returns the exit status of the program it invoked. If system() is returning 0 then that is what the program exited with. It's generally considered polite for programs that indicate errors to then exit() with a non-zero status, but this is by no means enforced anywhere. It could just be that the program is poorly designed.
One thing you could do is capture the program's STDOUT and/or STDERR streams and look for specific patterns, or at least anything at all. If anything is printed on STDERR it's a likely guess that an error occurred.
For information on capturing those, see IPC::Run, IPC::Open2 or IPC::Open3.
You should redirect STDERR to STDOUT by 2>&1 as follows:
my $myBcp = '"bcp.exe" <table name> in <temp file path> -f<format file> -m 1 -h "FIRE_TRIGGERS" -o<log file path>';
my $myResult = `$myBcp 2>&1`;
print $myResult;
In Perl I am starting a process using the nohup command. The command is below:
system("nohup myproc pe88 &");
This works fine and the process starts as expected. However I would like to suppress the following output of this command - which is:
Sending output to nohup.out
I must have this process redirecting all of it's output to nohup.out but I just don't want it displayed when I run my Perl program. I want to instead, print my own user friendly message. I've tried a few variants but nothing has worked for me yet.
"Sending output to nohup.out" message is sent to STDERR, so you can catch the STDERR via the usual methods
either via shell: system("nohup myproc pe88 2> /tmp/error_log.txt &");
Use /dev/null instead of /tmp/error_log.txt if you don't need stderr at all; and add "> /tmp/myout.txt" to redirect stdout.
Or by capturing via Perl (don't use system() call, instead use IPC::Open3 or capture command from IPC::System::Simple)
How about:
system("nohup myproc pe88 >nohup.out 2>&1 &");
The man page for nohup says:
If standard output is a terminal,
append output to 'nohup.out' if
possible, '$HOME/nohup.out' otherwise.
If standard error is a terminal,
redirect it to standard output. To
save output to FILE, use `nohup
COMMAND > FILE'.
So if you explicitly redirect STDOUT and STDERR to nohup.out, then nohup doesn't print that message. Granted, you don't get the automatic fallback to $HOME/nohup.out if nohup.out is unwritable, but you can check for that first if that's an issue.
Note that if you redirect just STDOUT, nohup prints a "redirecting stderr to stdout" message.