For some reason, when I type in commands I'm used to on linux, it works perfectly, as it does in bash... But in eshell, it doesn't work.
I've narrowed the problem to a trivial and small sample, as follows:
$ du
c:/Program: command not found
$ which bash
c:/Program Files (x86)/Git/bin/bash.exe
How do I get this working? (du is whatever it is by default... It's implemented in elisp, I haven't made any unusual changes there, that is, it's a compiled lisp function in `em-unix.el')
I would've expected something along the lines of "You have used 1.3 GiB of disk space", rather than that command not found error.
It doesn't use bash.exe, but it can use du.exe, when present.
On my system:
c: gutov $ which bash.exe
which: no bash.exe in ...
c: gutov $ which du.exe
h:/Apps/System/gnuwin32/bin/du.exe
From your error message I can tell that it calls some command and fails because it doesn't properly quote the path to executable (which contains spaces). Maybe you should do M-x report-emacs-bug.
Overall, I recommend:
1) Uninstall Git and reinstall it selecting the second option when asked about your PATH environment ("Run Git from the Windows Command Prompt"). This will remove the unix tools packaged with it from PATH.
2) Install in some directory without spaces and add to PATH unix tools from GnuWin32 project, or from Eli Zaretski's ports. The latter contains fewer packages overall, but it has a much faster find, for example. You can mix them.
Alternatively, maybe you can get away with just reinstalling Git into directory without spaces.
Related
I've been following along this quickstart guide:
https://docs.docker.com/compose/aspnet-mssql-compose/
Unfortunately I've come undone with this aspect:
Note: Make sure to use UNIX line delimiters. The script doesn’t work
if you use Windows-based delimiters (Carriage return and line feed).
I've tried downloading and running dos2unix on my .sh file, and I've tried in notepad++ using the Edit > EOL Conversion - UNIX (LF) option.
But whenever I run my docker-composer up I get this:
I'm working on a windows machine. My docker engine is running linux containers (as was default). Hoping to get this quickstart working so I can get my head around it better as I'm not 100% sure of the issue but it seems related to these return characters.
Give vim editor a shot. Use set ff=unix to have \n as a line separator. You'll need vim anyway when you'll be editing linux configs inside your containers.
If you don't want to fix your editor, install sed (from cygwin or unixtools) and run this command to fix your text files:
sed 's/\r//g' entrypoint-crlf.sh > entrypoint.sh
To develop linux software it's better to have linux handy. You can run your next favorite editor (vim/emacs) in docker too.
Even better is to have a mac or linux desktop. It's so much easier to deal with linux containers when your desktop is unix-flavoured. Some people have a linux VM and do all development there accessing with ssh.
I'm trying to use the Scala interactive shell, but the backspace key's behavior is strange. I'm finding that backspace does seem to delete the previous character, but it doesn't display that way on the line I'm typing... the cursor moves forward instead of backward. This makes it impossible to see what the current input line looks like.
I'm using Scala 2.11.12. I'm working in a terminal window on a Linux system, but xrdp'ing into the Linux host from a Windows 10 laptop. The backspace key works fine outside Scala (in zsh).
As a workaround, is there any control character that tells Scala to redisplay the current line? (Old OS's used to support characters that perform that function, if memory serves, but they haven't been necessary for a couple decades or so.)
I also encountered the same problem and improved by changing the setting of pyenv.
If the global setting of pyenv is not system, try changing to system.
Example:
$ pyenv versions
* system (set by /Users/*****/.pyenv/version)
2.7.10
3.5.0
anaconda3-5.2.0
Perhaps it's a bug of JLine, which scala use as a replacement of readline. But, if I empty the folder ~/.pyenv/shims, scala works fine. Then I execute pyenv rehash (which will bring back the files under shims), scala failed!
Then I remove the files in ~/.pyenv/shims half by half and it's a file named infocmp makes the difference. And it's not the content in it, but the exec permission that matters, i.e. chmod a-x ~/.pyenv/shims/infocmp will make scala work fine, but chmod a+x ~/.pyenv/shims/infocmp, even if infocmp is empty, the problem will occur!
May be I am close to the truth, but for now we can use chmod a-x ~/.pyenv/shims/infocmp to work around. And it needs only to be run once, because pyenv rehash will not overwrite a file if it already exists.
I have been installing Coq using the download links from the https://coq.inria.fr/ for both Windows and Mac. However, when I try coqc or coqtop on terminal or command prompt I get error messages saying that the command is not found. Although with that being said, I can still run Coq almost perfectly fine on the Coq IDE but when I compile buffer, in particularly the exercises from Software Foundations, i get the following message.
Running: coqc -I '/Users/zhangsheng/Desktop/G/repos/Coqy/cis500' '/Users/zhangsheng/Desktop/G/repos/Coqy/cis500/Basics.v' 2>&1
From what I understand, 2>&1 seems to be some form of misdirection and I feel that is the reason why coqc and coqtop don't seem to work on my terminal/command prompt.
Could someone kindly suggest the 'best' way to install Coq on either Mac or Windows or both such that I don't get the problems I mentioned above?
Although I am not a Windows or OSX user, I imagine that you're having this problem because the Coq installer does not update the system's PATH variable. This variable is a list of directories used by the terminal to look up the programs corresponding to commands you type. If you don't want to install Coq via a different method, you should probably find where the coqc and coqtop binaries are installed, and add these directories to your PATH. Here are a few references on how to do this: OSX, Windows.
I'm wondering if there is a tutorial or simple way to add perl scripts which I've written to be accessible to the user globally.
for eg. you apps like Carton, Cpanm, much like how npm has an npm install -g option.
I tried placing my scripts in the bin directory of my perl package but its not working.
The App::* area of cpan contains installable tools and utilities. Looking at a small one, like App::p I saw that its structure looked like it contained a Makefile.PL that used ExtUtils::MakeMaker to define how to build test and install the relatively small perl script.
However, if you're talking about just taking a script you wrote and making it something executable by you, the user, then it's basically the same way all scripting works (apologies if you weren't asking this):
One Unix, Linux and Mac OS X when using a shell like bash:
Any file can be made executable to the user by running chmod u+x filename
An executable file should start with a magic number, for plain text files containing scripts, the shebang is that number. So start your files with (as covered in man perlintro):
#!/usr/bin/perl
use strict;
use warnings;
When specifying an executable file from the command line you can type in the full path, possibly with conveniences from your shell. EG the file is at $HOME/myscripts/runme.pl you can type that at the prompt, the expanded /home/username/myscripts/runme.pl (/Users/username/myscripts/runme.pl on Mac OS X) or ~/myscripts/runme.pl at a bash prompt. Or if runme.pl is in your current working directory: ./runme.pl
If you just type runme.pl sh and bash and many shells will search your PATH variable in order and run the first runme.pl in any of the specified paths.
So if echo $PATH gives you something like: /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin and you want the example in point 3 to work with just runme.pl you should
Either move the file into one of those directories (not recommended).
Or add export PATH=$PATH:$HOME/myscripts to the bottom of your ~/.bashrc or ~/.profile file or likewise for your preferred shell. Be sure to open a new login shell session, EG close that terminal window and open a new one.
On Windows, this is an exercise left to the reader. ☺
I am using Emacs 23 and have the following problem:
I run our project's build system from within Emacs like M-x compile -> cd /foo/bar && ./build
The build system now does some magic, "cd"s into some subdirectory for the build process and then gcc throws an error:
../src/somesource.cc:50 error: blablabla
Now the problem is that Emacs won't find that path, because it assumes the compile process started out in /foo/bar, and not in /foo/bar/builddir. So the leading "../" is not working for Emacs, e.g. when running compile-goto-error. Is there a way to tell Emacs to try skipping leading "../"?
The best solution might be to change the build system to emit messages when it changes directories. Emacs looks for
Entering directory `...'
...
Leaving directory `...'
(See the compilation-directory-matcher variable. If your build system does emit messages when it changes directories, but they're not in the format Emacs is looking for, you can add new regexps to compilation-directory-matcher.)
The other solution is to change compilation-search-path (which is a list of directories).
On a few occasions I solved by passing output of the make through sed.
First, debugged it interactively 'Compile command: make | sed 's/x/y/' . And then repackaged it as a custom emacs interactive function.