I have a Cypress script running in the shell but when the log is printed, this is what I see:
19:37:34 [90m ┌[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m─[39m[90m┐[39m
19:37:34 [90m │[39m [90mCypress:[39m 6.3.0 [90m│[39m
19:37:34 [90m │[39m [90mBrowser:[39m Electron 87 [90m(headless)[39m
What should I add to my shell script to properly interpret these symbols [90m─ and [39m?
According to the Cypress documentations, if you want colors to be disabled, you can pass the NO_COLOR environment variable to disable colors.
So you would have a command like this:
NO_COLOR=1 cypress run
Related
I have some of the console commands I would like to use from Emacs, namely ag. It works great in CMD or Far Manager. However when I use it from Emacs shell or eshell I run into a problem which may be (slight chance, though) ag-specific.
When I run shell and then run ag it returns result (help screen) immediately. If I run it searching for a line in files inside directory as ag needle, it hangs and doesn't return anything.
If I run it as ag needle . it returns result immediately, however missing file names and lines numbers, --color and -nogroup options do not affect the printed result in this case.
When I run it via shell-command it returns the correct result (with file names and line numbers). eshell has the same problem.
What do I need to do to make these commands work in shell and/or eshell ?
It's been noted in the answers to this question that Win32 has issues with subprocess buffering. Is there a way to fix it?
#!/usr/bin/ruby
`cucumber feature/test.feature`
running the above code issue lots of cucumber feature/test.feature commands.. why ?
When i see processes list there are 30 to 50 processes running cucumber command
also ruby program never terminates
Try running your feature files from outside the 'features' folder. Think this will solve the issue.(tested using the command line)
User:project user$ ls
features
User:project user$cucumber example.feature
The first line instructs the shell to run myapp.rb, which is, AFAIU, this script itself. Namely, each execution of the script recursively runs itself again.
Try the following:
#!/usr/bin/ruby
`cucumber feature/test.feature`
Or, even better, directly from the CLI:
cucumber feature/test.feature
To run all the tests simply issue the cucumber command without args:
cucumber
I have wrote a simple shell script where I have only mentioned the following line
export LD_LIBRARY_PATH=/home/lib/
I want to run one program for which I have to link with this library ,before running the program I am running this shell script ,but after this the program is not working it showing the linking error and when I am doing following line it showing nothing
echo $LD_LIBRARY_PATH
but,when I am doing it in shell normally ,it is working.
Can any one tell why this shell script is not working.what is the concept behind it.
Thanks
If you want to run a script for the purpose of modifying environment variables you need to source the script rather than run the script. Running the script starts a new instance of w/e shell is used to run the script, when it returns, all environment variables are back to the way they were before you ran it. Doing "source script.sh" actually runs the commands in the script in your current shell.
I am writing a small script for watchr that runs my PHP unit tests.
Current script runs tests using system() and displays them colored.
I am trying to add libnotify functionality, but for that I need to parse the output and match against regexp, so that notification will either display green or red.
system() doesn't return output, %x does return, but puts p doesn't display colors, which I need to quickly see which test failed. One option would be to run tests twice - once for display in terminal window, and second time for checking which notification to show, but I would rather avoid it.
puts does display colors. The problem is when you run with %x your PHP test runner will most likely turn off colored output because it thinks it's not running under a terminal.
The same thing happens if you do run_php_test | less in the shell. To fix it you need to force colored output on the PHP test runner.
EDIT
Easiest way to run a subprocess with pty:
require 'pty'
puts PTY.spawn('run_php_test')[0].read
I've got a shell script that runs genReport.sh in order to create a .pdf formatted report, and it works perfectly when it's run from the command line. The data source for the report is a ClearQuest database.
When it's run from a CRON job the .pdf file is created, except that only the various report and column headers are displayed, and the data of the report is missing. There are no errors reported to STDERR during the execution of the script.
This screams "environment variable" to me.
Currently, the shell script is defining the following:
CQ_HOME
BIRT_HOME
ODBCINI
ODBCINST
LD_LIBRARY_PATH
If it's an environmental thing, what part of the environment am I missing?
Without seeing the scripts, it's only guesswork. It could be a quoting issue or something having to do with a relative path to a file or executable that should be absolute. Often, the problem is that the directories listed in $PATH are different in cron's environment than they are in the user's. One thing you can do to aid in the diagnosis is add this line to your script:
env > /tmp/someoutputfilename.$$
and run the script from the command line and from cron and compare.
The magic for making this run turned out to be evaluating the output of the clearquest -dumpsh command, which in turn required that the TZ variable be set. That command outputs a dozen or so variables.