I have a script that runs in the background which uses watch to monitor a directory for changes. This works just fine. However, I had a need for the script which runs the monitoring script to be run as daemon. The daemon is running as the same user, but now watch is returning "1 Various failures."
I suspect that there is some environment variable that is not set right, but there are too many to use trial and error to diagnose the issue. And unfortunately, "Various failures" is not very helpful. Any ideas how I might diagnose this?
The command is
watch -d -t -g ls -l
I think something like the following can be used as a work-around.
diff <(ls -l) <(sleep 1; ls -l)
I finally discovered the following on stderr.
Error opening terminal: unknown.
It was easily resolved by the answer to error opening terminal. So it did turn out to be an environment variable. I don't see this error message in the code. Perhaps it occurs when making a system call that needs the terminal.
Related
So I'm getting some pretty strange behaviour when I try to use an Automator service to open new emacs (GNU Version 25.2 with spacemacs) buffers.
In my terminal, the command emacsclient -a '' -c works as expected, opening a new buffer through emacsclient. However, when I make a service in Automator which simply runs a (/bin/bash) shell script:
emacsclient -a '' -c
I get an error message:
The action “Run Shell Script” encountered an error: “emacsclient: could not get terminal name”
On suspicions that this was due to Automator not using some default PATH variable, I tried the following instead:
PATH=/usr/local/bin:$PATH
emacsclient -c
which produced the same error as before.
Next I tried
PATH=/usr/bin:/usr/local/bin export PATH;
emacsclient -c
which produced a different error message:
The action “Run Shell Script” encountered an error: “emacsclient: invalid option -- c
Try `emacsclient --help' for more information”
however why I try that script in my terminal it also gives a similar error which doesn't make much sense to me.
If anyone has suggestions for how to fix this I'd really appreciate it.
The problem is the shell script is running an old version of emacsclient in /usr/bin you need to run the one in Emacs.app/Contents/MacOS/bin/emacsclient. Delete the PATH line and you can use a solution listed here for running emacsclient inside automator Running a macOS service for open with emacs failed with "emacsclient: could not get terminal name mac"
I'm new to mojolicious but have been using Perl for some time. I have to jump through some hoops but I can get the interactive Perl debugger (and Komodo) working with remote connections for Apache but I can't find anything about interactive debugging with hypnotoad or morbo.
The command line examples in the basic tutorial on http://mojolicio.us/perldoc/Mojolicious/Guides/Tutorial#Hello-World work fine because you can launch them with perl -d, but I don't see anyway to tell the hypnotoadctl script to put the service in interactive debug mode ala apache.
Is this not possible? Hints? Tips? Pointers?
morbo and hypnotoad are perl programs, so you can launch them with the -d switch.
perl -d $(which morbo) myMojoApp.pl
It's probably easiest to sprinkle a bunch of $DB::single = 1 statements around you app where you want your initial breakpoints to go and run c as the first debugger command. When you run a request that hits a breakpoint, you'll get a debugger prompt in the terminal that launched morbo.
hypnotoad will be trickier to use with the debugger because it quickly closes all the standard filehandles, calls fork several times, and becomes a daemon.
As JHThorsen points out, standard Mojolicious tests are actually ordinary Perl scripts, so you can debug your tests with:
perl -d t/mytest.t
The -Ilib adds the lib/ directory to the #INC include list so your modules will be loaded.
One catch is that many modules are not loaded until execution time, so if the debugger hassles you about symbols that aren't loaded yet, you'll probably want to set breakpoints after forcing a debug prompt with a carefully inserted
$DB::single = 1;
Thanks to 'pink_mist'. You can do:
perl -d myMojoApp.pl daemon -l http://*:29849
But application config is not applyied. I do not know why.
I am having a strange issue. I have written a script which is basically running a perl script in remote server using ssh.
This script is working fine but after completion of the above operation it will ask user to choose the next operation.
it is showing the options in the command prompt but while I am giving any input it is not showing in the screen even after hitting enter also it remain same.
I am not getting what is the exact issue, but it seems there is some issue with the ssh command because if I am commenting out the ssh command it is working fine.
OPERATION:
print "1: run the script in remote server \n2: Exit\n\nEnter your choice:";
my $input=<STDIN>;
chomp($input);
..........
sub run_script()
{
my $com="sshg3.exe server -q --user=user --password=pass -exec script >/dev/null";
system("$com");
goto OPERATION;
}
after completing this ssh script it is showing in screen:
1: run remote script
2: exit
Enter your choice:
but while I am giving any input it is not displaying in the screen until and unless I am exiting it using crtl C.
Please can anyone help what might be the issue here ?
One of the classic gotchas with ssh is this - that it normally runs interactively, and as such will attach STDIN by default.
This can result in STDIN being consumed by ssh rather than your script.
Try it with ssh -n instead.
You can redirect the output in command prompt if -n option is not available for you.
try this one it might work for you.
system("$com />null");
As per https://support.ssh.com/manuals/client-user/62/sshg3.html there is an option for redirecting input use --dev-null (*nix) or --null (Windows).
-n, --dev-null (Unix), -n, --null (Windows)
Redirects input from /dev/null (Unix) and from NUL (Windows).
Running UIAutomation tests from the command line seems to break often with new Xcode releases (judging by past posts). Having never used the command line scripting for this, I found this post from 2012: Automation Instrument from the Command Line.
The Problem: My command returns without error, without output results and without anything logged to the system console. The simulator does not even launch!
Checking some of the paths for updates (notably, the Automation trace instrument path), I came up with this command. Note the path in the first parameter (it's different than in past Xcode releases):
instruments -t "/Applications/Xcode.app/Contents/Applications/Instruments.app/Contents/PlugIns/AutomationInstrument.xrplugin/Contents/Resources/Automation.tracetemplate"
"/Users/sohail/Library/Developer/CoreSimulator/Devices/7232A640-A9D2-4626-A2AD-37AFFF706718/data/Containers/Bundle/Application/D07FEC4B-76AD-4844-8362-08E771B81053/MyAppName.app"
-e UIASCRIPT "/Users/sohail/source/MyAppName/MyAppNameAutomationTests/TestRunner.js"
-e UIARESULTSPATH "Users/sohail/source/MyAppName/MyAppNameAutomationTests/TestResults"
This might be easier to read by selecting "raw" from this gist.
Of course:
I validated that the path specified to my .app actually exists; it came into being after a successful build and run.
I validated that in my specified output folder ("TestResults") that in fact, nothing got logged.
I validated that the aforementioned TestRunner.js file I specified, could be found at the path specified, and successfully runs in the Automation Instrument interactively with the Instruments app.
I've checked Apple's Xcode6/iOS8 pre-release documentation (login required; see section title, "Executing an Automation Instrument Script from the Command Line"), and nothing jumps out at me as wrong, since I'm just targeting the simulator.
My suspicion
I'm missing some flag or switch somewhere.
Thoughts anyone?
I saw the exact same issue, after explicitly provided -w $DEVICE parameter, my tests finally got started
instruments -t /Applications/Xcode6.app/Contents/Applications/Instruments.app/Contents/PlugIns/AutomationInstrument.xrplugin/Contents/Resources/Automation.tracetemplate
-w "iPhone 5s (8.0 Simulator)" /path/to/my/TestApp.app -e UIASCRIPT /tmp/script.js -e UIARESULTSPATH /tmp
Permission denied (publickey,keyboard-interactive) got this error while i am trying to cvs checkout from perl.
what is issue and how to reslove this ?
Code :
system ( "CSVROOT:--- CVSRSH:--- cvs co a ");
# i have proper value in cvs root and cvs rsh .
its running alone and using ssh key
Steps to diagnose the error:
Are you using an SSH key?
Does that key have a passphrase?
Does it work when you run it by hand?
Is the script running as the same user as when you run it by hand?
Is the script running under the same environment as when you run it by hand? (e.g. cron jobs do not run under the same environment)
If you think all of the answers are yes, then most likely the last answer is really no. If the script is running from a scheduler like cron it most likely does not run with the same environment as when you run it by hand. The way I normally solve this is to use a shell script between the scheduler and the Perl script:
#!/bin/bash
source /home/USERNAME/.profile
#set any other environment variables it needs like
export CSVROOT=:pserver:USERNAME#HOST:/path/to/repo
export CVSRSH=ssh
/path/to/perl/script/script.pl
Follow-up investigations after Chas.'s questions:
Does that command normally run under /bin/sh or some other shell?
To test, execute /bin/sh command to start Bourne shell and try the command by hand again.
I'm not familiar with "CVSROOT:---" notation - is that meant to set CVSROOT environmental variable? In Bourne shell it's usually done using "=", never saw ":" used.
Does the command, when run by hand, expect some input from you? I never saw cvs co to do so, but I don't use it with ssh.
Try to add a redirect to the end of the command and look what's in the file after running:
system ( "CSVROOT:--- CVSRSH:--- cvs co a > /tmp/log_cmd 2>&1");