Mocha is installed globally on Windows, but cmd shows "mocha is not an internal or external command, nor is it a runnable program or batch file"
Mocha (test framework for Node.js) uses make and on Windows machine, such errors occur a lot. I guess, at the time of execution it's not recognizing the path. So, you can follow any of the 2 below:
1) Install mocha globally(if not done already) so that it works in the regular windows command line:
npm install -g mocha
Then run your tests with mocha path\to\test.js
OR
2) Other way to deal with this is to use Cygwin and ensure that the developer packages for Cygwin are installed.
Read this article, it will help you: https://altamodatech.com/blogs/?p=452
On installation, the location of mocha.cmd is not added to path. If you install globally, as #hemanshu suggests, that location is %APPDATA%\npm. So, you either add that to your path, or (as I do) define an alias; my cmd.exe shortcut loads a script to set the path to things actually useful in the command line, set environment variables, etc, and in there I have this:
#doskey mocha=%APPDATA%\npm\mocha.cmd
Related
I installed bit on my Ubuntu 22.04 machine using npx #teambit/bvm install, which created an executable in my HOME/bin folder and an entry on my .zshrc
Now, I would like to know if anything else was installed, and how can I completely remove Bit from my machine.
Ideally, I would like to know which code was run when doing npx #teambit/bvm install
I use volta to install nodejs https://volta.sh/
Answering this question requires some context.
First and foremost, #teambit/bvm produces side-effects in the ~/.bvm/ directory (see code here - https://github.com/teambit/bvm). To delete Bit and BVM completely, you need to manually remove that directory.
In general, npx doesn't have a way to revert side effects by packages/commands you run through it (if they do produce any side effects).
There's no way to get npx to undo what any tool did, as npx doesn't force any boundaries on tools.
At the end of the day, you need to delete each tool per to its own instructions.
The only thing that npx does is creating the ~/bin/bvm (in the case of #teambit/bvm, for other tools naming will be different). This is a shortcut for the command that the package-manager puts in place. It's unrelated to bvm or bit. npx may also place things in global node_modules or do other npm-related things.
I'm working on a project that uses the proxygen library by facebook.
The latter builds itself by means of a script called deps.sh which uses to invoke apt-get as a super user.
I've successfully created a custom target with cmake using the add_custom_target directive, but it fails because of the above call with the error sudo: no tty present and no askpass program specified and it makes sense, of course.
Anyway I've not been able to find a way of executing that script, thus invoking a command as a super user, using the add_custom_target.
I can safely install the library and write a FindProxygen module for my colleagues, so that the build process remains coherent, but I'd like to know if there is a clean solution to the problem of launching a command as root from cmake and thus put the library as a submodule of the project.
You can run installation script in new terminal, so sudo, executed by this script, will work as usual.
COMMAND x-terminal-emulator -e "<...>/deps.sh"
(This may be written as part of add_custom_target, add_custom_command, execute_process, etc.)
add_custom_target(
apt-downloads ALL
COMMAND sudo apt install -y ${DEPENDENCY_LIBRARIES}
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
COMMENT "download required dependencies straight from apt on ubuntu"
)
Worked for me
The response is pretty simple: no.
As remarked in the comments, cmake expects to find all the required libraries already installed in the system (or at least, within the search paths) and any other solution would stop the execution and wait for user inputs.
As far as I've seen around, the usual approach, the one I've used too in the above mentioned project and in another one started immediately after, is to create a script that is in charge to download, compile and prepare the project environment, the same way proxygen itself does.
The final user will be asked to firstly executes that script, thus he will be able to proceed using cmake.
That's all, thank you for the comments.
When building the project from command line using mvn clean install everything builds without any issues.
When running some tests that use precompiled C libraries from IntelliJ, tests fail with java.lang.UnsatisfiedLinkError
I may be completely off here, but does IntelliJ not see the .so file? Is so, how can it be added please?
Shared library fails to load with UnsatisfiedLinkError if:
it's not in the working directory configured in the test run configuration.
it's not in PATH environment (on Mac Terminal and GUI apps have different environment, see this answer). Run IDEA from the Terminal open -a /Applications/IntelliJ\ IDEA\ 12.app/ to make environment the same.
it's not in the location specified using -Djava.library.path VM option.
.so depends on some other library that is not found for any of the 1-3 reasons (or the dependency of that dependency is not found, etc).
What should I use if I want to use less.js locally and have a file automatically recompiled if either this file or an imported file has changed?
lessphp is a LESS compiler written entirely in PHP, making it very easy to run on the server side if you're already using PHP. It was finally just added to Packagist yesterday! You can install it on a project to project basis using composer. Here is an example composer.json file for declaring it as a dependency to your own project:
{
"require": {
"leafo/lessphp": "dev-master"
}
}
You can also use dotless with mono.. if you have mono then run dotless with the -w (watch) option.
You could use watchdog and this script, which I found useful.
To install watchdog, you’ll first need to have the python setup tools installed (apt-get install python-setuptools assuming you’re using Debian or a Debian-based distribution such as Ubuntu).
Then, simply easy_install watchdog. You'll be able to run the lesswatch script once the installation is complete.
I just built Rakudo and Parrot so that I could play with it and get started on learning Perl 6. I downloaded the Perl 6 book and happily typed in the first demo program (the tennis tournament example).
When I try to run the program, I get an error:
Divide by zero
current instr.: '' pc -1 ((unknown file):-1)
I have my perl6 binary in the build directory. I added a scripts directory under the rakudo build directory:
rakudo
|- perl6
\- scripts
|- perlbook_02.01
\- scores
If I try to run even a simple hello world script from my scripts directory I get the same error:
#!/home/daotoad/rakudo/perl6
use v6;
say "Hello nurse!";
However if I run it from the rakudo directory it works.
It sounds like there are some environment variables I need to set, but I am at a lost as to what the are and what values to give them.
Any thoughts?
Update:
I'd rather not install rakudo at this point, I'd rather just run things from the build directory. This will allow me to keep my changes to my system minimal as I try out different Perl6 builds (Rakudo * is out very soon).
The README file encouraged me to think that this was possible:
$ cd rakudo
$ perl Configure.pl --gen-parrot
$ make
This will create a "perl6" or "perl6.exe" executable in the
current (rakudo) directory. Programs can then be run from
the build directory using a command like:
$ ./perl6 hello.pl
Upon rereading, I found a reference to the fact that it is necessary to install rakudo before running scripts outside the build directory:
Once built, Rakudo's make install target will install Rakudo
and its libraries into the Parrot installation that was used to
create it. Until this step is performed, the "perl6" executable
created by make above can only be reliably run from the root of
Rakudo's build directory. After make install is performed,
the installed executable can be run from any directory (as long as
the Parrot installation that was used to create it remains intact).
So it looks like I need to install rakudo to play with Perl 6.
The next question is, where rakudo be installed? README says into the Parrot install used to build.
I used the --gen-parrot option in my build, which looks like it installs into rakudo/parrot-install. So rakudo will be installed into my rakudo\parrot-install?
Reading the Makefile, supports this conclusion. I ran make install, and it did install into parrot_install.
This part of the build/install process is unclear for a newbie to Perl6. I'll see if I can up with a documentation patch to clarify things.
Off the top of my head:
Emphasize running make install before running scripts outside of build. This requirement is currently burried in the middle of a paragraph and can be easily missed by someone skimming the docs (me).
Explicitly state that with --gen-parrot will install perl6 into the parrot_install directory.
Did you run make install in Rakudo?
It's necessary to do it to be able to use Rakudo outside its build directory (and that's why both the README and http://rakudo.org/how-to-get-rakudo tell you to do it.
Don't worry, the default install location is local (in parrot_install/bin/perl inside your rakudo directory).
In response to your update I've now updated the README:
http://github.com/rakudo/rakudo/commit/261eb2ae08fee75a0a0e3935ef64c516e8bc2b98
I hope you find that clearer than before. If you still see room for improvement, please consider submitting a patch to rakudobug#perl.org.