% uname -a
Linux xxxxxxx 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
% emacs --version
GNU Emacs 26.3
Copyright (C) 2019 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
% gnome-terminal --version
# GNOME Terminal 3.36.1.1 using VTE 0.60.3 +BIDI +GNUTLS +ICU +SYSTEMD
% emacs -nw test.c
when editing..
stroke "Ctrl-g"
crashed and display prompt
%
why??
Try emacs -nw -Q test.c.
That is, try Emacs without your init file: emacs -Q.
Then bisect your init file to find the culprit.
Related
I noticed this problem in my terminal some time ago, but I did not find a solution, is there any suggestion to solve this problem please
Thanks :)
My devise (MacBook Air M1)
system used macOS 13.0
vim --version
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Jul 12 2022 16:34:31)
macOS version - x86_64
Included patches: 1-50
Calling Vim with the -y flag is equivalent to calling evim:
$ vim -y
See :help evim.
If you prefer to type evim instead of vim -y, you can add an alias to your shell's configuration file:
$ echo 'alias evim="vim -y"' > ~/.zshrc
Now, your real problem seems to be that you have the string evim at the top of ~/.zshrc. Could you show us the file's content?
$ cat ~/.zshrc
I have a strange behavior when the executing a program in a MSYS shell version 5.1.8. I'm on Windows 10 Version 22H2 (OS Build 19045.2251). The strange behavior occurs when a path is on a drive created with subst.
The following steps can be used to reproduce the behavior.
Inside a Windows CMD
C:\Users\f.redeker>subst s: "C:\Program Files\Common Files\System"
C:\Users\f.redeker>subst
S:\: => C:\Program Files\Common Files\System
Inside a shell version 5.1.8
sh-5.1$ uname -a
MSYS_NT-10.0-18362 MIMIR-W10-64 3.2.0-340.x86_64 2021-07-02 08:36 UTC x86_64 Msys
sh-5.1$ sh --version
GNU bash, version 5.1.8(1)-release (x86_64-pc-msys)
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
sh-5.1$ realpath /s/ado/msadox.dll
/s/ado/msadox.dll
sh-5.1$ cd /s
sh-5.1$ pwd
/s
sh-5.1$ realpath ado/msadox.dll
/s/ado/msadox.dll
sh-5.1$ cd ado
sh-5.1$ pwd
/s/ado
sh-5.1$ realpath msadox.dll
/c/Program Files/Common Files/System/ado/msadox.dll
But
sh-5.1$ realpath /s/ado/sadox.dll
/s/ado/msadox.dll
Inside a shell version 4.4.19
sh-4.4$ uname -a
MSYS_NT-10.0-18362 MIMIR-W10-64 3.2.0-340.x86_64 2021-07-02 08:36 UTC x86_64 Msys
sh-4.4$ sh --version
GNU bash, version 4.4.19(2)-release (i686-pc-msys)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
sh-4.4$ cd /s
sh-4.4$ pwd
/s
sh-4.4$ realpath ado/msadox.dll
/s/ado/msadox.dll
sh-4.4$ cd ado
sh-4.4$ pwd
/s/ado
sh-4.4$ realpath msadox.dll
/s/ado/msadox.dll
With Process Monitor I have observed that the shell does not directly start the program to be executed, but first another shell. When creating this shell it seems that the current directory is given when CreateProcess is called.
Here, however, not the path with the subst drive is used but the one to which the subst drive points. Due to this behavior the Windows functions (e.g. _fullpath or GetFullPathName) do not return the result with the subst path if not an absolute path is specified as input parameter.
Is there any way to preserve the old behavior in current MSYS version?
I recently installed g++-10 with Homebew on my MacOS 10.14.6. I created an alias in my .zshrc file:
alias g++="/usr/local/bin/g++-10"
to automated compile and run in terminal I created a .sh file. However, I noticed that the version of g++ used when calling g++ manually from terminal is the following:
$ g++ --version
g++-10 (Homebrew GCC 10.2.0) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
which is not the same than the one which calls g++ from the .sh script. The content of the script displayg++Version.sh is:
type g++
g++ --version
and then the output of the call of the script is:
g++ is /usr/bin/g++
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
Here is the output of the following command:
$ type g++
g++ is an alias for /usr/local/bin/g++-10
Why do both versions differ?
First of all, alias definitions are ignored in a script, unless explicitly enabled. You can turn this on by doing in your script a
setopt aliases
but don't forget that this affects only aliases which are defined afterwards, not before.
Second, .zshrc is not processed by a zsh script unless explicitly enabled. From the zsh man-page:
If the shell is interactive, commands are read from /etc/zshrc and then ZDOTDIR/.zshrc.
You can force interactivity by running your script with the -i option:
zsh -i your_script.zsh
If you want a certain g++ version to be executed in your zsh script, the usual solution is however to adjust the PATH so that zsh can find the right version. For instance:
PATH=/your/path/to/g++:$PATH zsh your_script.zsh
If you always want this g++ version to be used, you would of course set your PATH in your .zshrc accordingly. Since your command shell is interactive, the .zshrc will be processed, and since PATH is an environment variable, your script will peruse this PATH withou your need to do anything special.
In which file are stored the info about the command
bash --version
?
I've tried in some directories like /bin or /var, /etc, but without results...
I need both for Linux and MAC OS x. Thanks!
Do you have any reason to believe that it is not hard-coded in the bash-executable itself?
To find out which bash is used, run
which bash
For me, it gives /bin/bash. Now, to see whether the executable has any string-like byte sequences in it that contain the substring "version", run
strings /bin/bash | grep version
On this machine, it gives:
shell_version_string
build_version
sccs_version
rl_library_version
rl_do_lowercase_version
show_shell_version
rl_readline_version
dist_version
GNU bash, version %s-(%s)
GNU bash, version %s (%s)
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
#(#)Bash version 4.3.48(1) release GNU
display-shell-version
-l do not print tilde-prefixed versions of directories relative
HOSTTYPE The type of CPU this version of Bash is running under.
OSTYPE The version of Unix this version of Bash is running on.
version, type `enable -n test'.
do-lowercase-version
.gnu.version
.gnu.version_r
Thus, "Bash version 4.3.48" is hard-coded in the executable as an ordinary string.
strings $(which bash) | grep "Bash version"
Output (e.g.):
#(#)Bash version 4.3.48(1) release GNU
File: test.txt (yes, just those 4 characters)
#(:/
Bash script file: test.sh
#!/bin/bash
# Get the entire content
content=`cat ./test.txt`
echo $content
I'm running this version of bash on Ubuntu (this works fine on OS X but I need it to work on Ubuntu)
Bash Version:
vagrant#vagrant-ubuntu-trusty-64:/vagrant$ bash --version
GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
Ubuntu version:
Linux vagrant-ubuntu-trusty-64 3.13.0-66-generic #108-Ubuntu SMP Wed Oct 7 15:20:27 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
It's annoying as hell because bash just hangs and never completes. Really curious to know if there are some rules I'm just not familiar with for certain versions of Bash.
Also, if you don't have the exact same version and it works fine for you, please don't post and say "It worked fine for me". The point of this post is not to hear how great it works for you under completely different circumstances. The point is to understand why it doesn't work under these very specific circumstances.
Thanks for all the great comments. While I still don't know the reason for the problem, it's pretty clear that it's important to quote bash variables when they might contain unexpected text combinations. In this case, the solution from #tripleee worked properly.
Properly working script:
#!/bin/bash
# Get the entire content
content=$(cat ./test.txt)
echo "$content"