I just installed clean-css (https://github.com/GoalSmashers/clean-css) via npm command line and I would like to use it to concatenate and minify some css files (duh). However, I am getting this error:
'cleancss' is not a recognized as an internal or external command, operable program or batch file.
I am new to doing things from the command line so this completely throws me for a loop. I couldn't find an answer to this clean-css specific issue. The general answer for this type of error seems to be that the environment variables need to by updated but while I have done that in the past to point to certain executable files I am not sure what I would have to do in this particular scenario. Any takers?
Try installing in with
npm install -g clean-css
Using the global option should make it available in your shell.
I was experiencing this problem and, as of 4.0, clean-css-cli needs to be installed. I take no credit I merely found the answer here:
https://stackoverflow.com/a/41912485
Related
I am trying to set up meteor-jsdoc on an existing meteor project according to the steps here:
https://www.npmjs.com/package/meteor-jsdoc
I am using windows and I run >npm install -g meteor-jsdoc , it is successfully
However when I try to run > meteor-jsdoc, it gives the error as in title.
I tried running the npm install both inside and outside the folder.
Anyone had the experience before? I am really stuck here.
Thanks!
Found the solution, re-installed git bash with unix tools option selected.
So I'm using the new Bash on Ubuntu on Windows shell, and installed the clisp package to mess with Common Lisp. I get this error when I try clisp test.clisp:
/usr/lib/clisp-2.49/base/lisp.run: error while loading shared libraries: libavcall.so.0: cannot enable executable stack as shared object requires: Invalid argument
This is an entirely fresh install too. I looked in /usr/lib and found the libavcall.so.0 file, but I'm not sure what to do with it. How do I fix this issue?
This issue no longer exists with libffcall 2.0 or newer. It was fixed through this commit.
If you are still using libffcall 1.x: The FAQ (cited by user #cybevnm) explains most of it:
libavcall.so is flagged as requiring executable stack (property GNU_STACK has the value RWE), although it does not need an executable stack. This occurs because it was compiled from assembly-language source code.
You can remove this flag through a command such as sudo execstack -c /usr/lib/libavcall.so.0.
Typescript compilation task works fine on linux machines but on a mac fails with the following not particularly useful error message and what looks like a binary dump.
$ grunt
Running "ts:build" (ts) task
Compiling...
Fast compile will not work when --out is specified. Ignoring fast compilation
Using tsc v1.4.1
������������=��AF���=����
>> Error: tsc return code: 3
Warning: Task "ts:build" failed. Use --force to continue.
Aborted due to warnings.
Im using nvm with node v0.11.4 and rvm with ruby v2.2.0.
Any ideas how to fix this, or even debug?
As the question includes debugging, here are some pointers which might help determine where the problem is.
Try compiling from the command line with tsc alone (no grunt), in case the problem is with grunt or the ts:build task (looks like grunt-ts).
Maybe one of your source files is causing the tools to crash (perhaps they can't cope with a file's encoding?). If a single, simple file will compile, then try removing subsets of your source from the build. If some of those files are causing the crash (whether valid TypeScript or not) you may be able to find a temporary workaround.
Try compiling with different versions of tsc. If you need 1.4.1 features you could try using the latest from https://github.com/Microsoft/TypeScript (see here for how to do this with grunt-ts).
The problem was with a malfunctioning node installation. I upgraded to node 0.12 which fixed the problem.
Just to check the problem wasn't node 0.11.4 specific I removed all previous versions of node and reinstalled 0.11.4 and the error no longer occurs.
I took these steps after removing all node modules, clearing the cache and reinstalling with no luck. I also tried using multiple typescript compiler versions.
When compiling with -fsanitize=memory I get WARNING: Trying to symbolize code, but external symbolizer is not initialized! when running the program. How do I initialize the external symbolizer?
I solved my own problem using MSAN_SYMBOLIZER_PATH=$(which llvm-symbolizer-3.4) ./a.out. The problem is that Ubuntu postfixes the version number but the binary doesn't know that. Of course you need to use MSAN instead of ASAN when using the memory sanitizer.
You are supposed to be able to set the ASAN_FILTER environment variable to point at a symbolizer, but I could not get it to work. However, you can redirect stderr into a symbolizer after the fact. You'll still get the warnings about the uninitialized symbolizer, but the filenames and line numbers will be correct.
You can use asan_symbolizer.py as the external symbolizer. After downloading it from that link (to /tmp, for example), invoke your program like so (in bash, for this example):
./myprogram 2>&1 | /tmp/asan_symbolize.py | c++filt
On my Ubuntu system, the issue is that LLVM's tools are installed under /usr/bin with version suffixes (like llvm-symbolizer-4.0), and the sanitizer tools are looking for them without version suffixes.
LLVM also installs its binaries to, e.g., /usr/lib/llvm-4.0/bin; the tools under /usr/bin are actually just symlinks. So an easy solution is to add the appropriate /usr/lib/llvm-*/bin directory to your path when working with sanitizers.
I received such warning when I run program debug version (compiled with -fsanitize=address) on Linux machine that didn't contain clang installation. The problem disappeared after I installed clang from devtoolset.
I am trying to compile Network.HTTP (http://hackage.haskell.org/package/network) on win32/cygwin. However, it does fail with following message:
Setup.hs: Missing dependency on a foreign library:
* Missing (or bad) header file: HsNet.h
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
If the header file does exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
Unfortuntely it does not give more clues. The HsNet.h includes sys/uio.h which, actually should not be included, and should be configurered correctly.
Don't use cygwin, instead follow Johan Tibells way
Installing MSYS
Install the latest Haskell Platform. Use the default settings.
Download version 1.0.11 of MSYS. You'll need the following files:
MSYS-1.0.11.exe
msysDTK-1.0.1.exe
msysCORE-1.0.11-bin.tar.gz
The files are all hosted on haskell.org as they're quite hard to find in the official MinGW/MSYS repo.
Run MSYS-1.0.11.exe followed by msysDTK-1.0.1.exe. The former asks you if you want to run a normalization step. You can skip that.
Unpack msysCORE-1.0.11-bin.tar.gz into C:\msys\1.0. Note that you can't do that using an MSYS shell, because you can't overwrite the files in use, so make a copy of C:\msys\1.0, unpack it there, and then rename the copy back to C:\msys\1.0.
Add C:\Program Files\Haskell Platform\VERSION\mingw\bin to your PATH. This is neccesary if you ever want to build packages that use a configure script, like network, as configure scripts need access to a C compiler.
These steps are what Tibell uses to compile the Network package for win and I have used this myself successfully several times on most of the haskell platform releases.
It is possible to build network on win32/cygwin. And the above steps, though useful (by Jonke) may not be necessary.
While doing the configuration step, specify
runghc Setup.hs configure --configure-option="--build=mingw32"
So that the library is configured for mingw32, else you will get link or "undefined references" if you try to link or use network library.
This combined with #Yogesh Sajanikar's answer made it work for me (on win64/cygwin):
Make sure the gcc on your path is NOT the Mingw/Cygwin one, but the
C:\ghc\ghc-6.12.1\mingw\bin\gcc.exe
(Run
export PATH="/cygdrive/.../ghc-7.8.2/mingw/bin:$PATH"
before running cabal install network in the Cygwin shell)