For a command like this one on Linux debian-linux 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64 GNU/Linux with xfce I get :
alain#debian-linux:~$ dbus-send --system --type=method_call --print-reply --dest
=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListActivatable
Names
The same command on OpenBSD LeOpenBSD 6.4 GENERIC.MP#364 amd64 with xfce I get :
ktop/DBus org.freedesktop.DBus.ListActivatableNames <
On linux, at the end of screen, we go to next line.
On BSD(OpenBSD-NetBSD), the command line continue on the same line and the first words disapear.
It's the same in xfce-terminal-emulator, xterm or in TTY (Alt-Ctrl-F3)
I try to add am in gettytab in the defaut section with no avail.
Termcap man page say :
If the display wraps around to the beginning of the next line when the cursor reaches the right margin, then it should have the am capability.
What can I do ?
Short answer
If you want to your current shell without this feature
set +o emacs
If you want to spawn a new shell without this feature
ksh +o emacs
Long answer
This behavior is mainly due to the shell input interactive editing mode supported on OpenBSD.
In these editing modes, if a line is longer than the screen width (see the COLUMNS parameter), a ‘>’, ‘+’, or ‘<’ character is displayed in the last column indicating that there are more characters after, before and after, or before the current position, respectively. The line is scrolled horizontally as necessary.
If you want to remove this feature, you can use set build-in command present in sh or ksh. You can also remove this flag during invocation by using +o
Finally, if you want to check if some interactive editing modes are enabled on your current shell, you can invoke set -o or set +o without argument. It will give you something like that, here the set -o command:
$ set -o
Current option settings
allexport off keyword off notify off verbose off
braceexpand on login on nounset off vi off
bgnice off markdirs off physical off viraw off
csh-history off monitor on posix off vi-show8 off
emacs off noclobber off privileged off vi-tabcomplete on
errexit off noexec off restricted off vi-esccomplete off
gmacs off noglob off sh off xtrace off
ignoreeof off nohup on stdin on
interactive on nolog off trackall off
and here the set +o command:
$ set +o
set +o allexport -o braceexpand +o bgnice +o csh-history +o emacs +o errexit
+o gmacs +o ignoreeof -o interactive +o keyword -o login +o markdirs -o monitor
+o noclobber +o noexec +o noglob -o nohup +o nolog +o notify +o nounset
+o physical +o posix +o privileged +o restricted +o sh -o stdin +o trackall
+o verbose +o vi +o viraw +o vi-show8 -o vi-tabcomplete +o vi-esccomplete
+o xtrace
I think what you're actually describing may be a difference between the two very different shells used on Linux and most BSDs and their very different command-line editing implementations.
This probably has nothing to do with differences between various terminal emulator implementations; nor with differences between terminal capabilities databases describing those terminal emulations.
On the BSD system(s) the default shell's command-line editor scrolls the whole like across the width of the screen depending on the position of the cursor. On some Linux systems I've seen the default shell's command-line editor wrap long lines around to continue on the next line.
Related
zsh doesn't recognize options set with -o, but only when its in a shebang, and on Linux.
The following script fails on zsh 5.0.2, zsh 5.6, and the latest git:
#!/bin/zsh -o pipefail
thiswillfail | echo 'hello, world'
echo $?
exit
Expected Output
hello, world
/home/prajjwal/script:2: command not found: thiswillfail
127
Actual Output
/bin/zsh: no such option: pipefail
What works
The script on zsh 5.3 on MacOS Mojave. This appears to be failing on every Linux version I've tried so far, though.
Manually invoking /bin/zsh -o pipefail on a terminal
Setting the option with set -o pipefail after the shebang in the script.
What I've tried
Emptying my .zshrc's to ensure one of my settings isn't causing this.
Aside
While I'm only trying to get pipefail to work, this refuses to work with any other options that I try to set, even though all of them are mentioned in zshoptions.
This is a pitfall of trying to set options on the #! line. The kernel only splits the shebang line at the first space.
When you say
#!/bin/zsh -o pipefail
the command that ends up being executed is "/bin/zsh" "-o pipefail" "/home/prajjwal/script".
The error message says that " pipefail" (note the leading space) is not a valid option, which is correct: Only "pipefail" is valid.
In this case a possible workaround is to cram everything into a single command line argument:
#!/bin/zsh -opipefail
But in general that's not possible and the #! interface doesn't let you pass more than one extra argument, so your choices are to find other workarounds (e.g. using set manually) or to write a wrapper script:
#!/bin/zsh
exec /bin/zsh -o pipefail /path/to/the/real/script
On some systems another alternative is available: env -S. This option is not specified by POSIX and is not available on all systems. It works on systems using the GNU tools (including all standard Linux distributions) and FreeBSD, but not OpenBSD or NetBSD. I couldn't find any information about MacOS.
(Note: GNU env also supports --split-string as an alternative (long) option name, but FreeBSD env does not.)
Usage:
#!/usr/bin/env -S /bin/zsh -o pipefail
This invokes env with a single long argument ('-S /bin/zsh -o pipefail'). Standard option processing treats it as the -S option followed by an argument (' /bin/zsh -o pipefail').
In a simple case like this, env -S splits the argument on spaces/tabs and treats the resulting list as if it had been part of the original command line in the first place:
env -S ' /bin/zsh -o pipefail'
# works the same as:
env /bin/zsh -o pipefail
In less simple cases you'll have to quote some characters (env -S treats spaces, ", ', \, $ specially, among others). In particular, it does not work like shell quoting. For details refer to the manual pages linked above.
Does bash shell script leave the history of the commands it executed, such as .bash_history?
I'm curious about it.
No, it does not:
https://www.gnu.org/software/bash/manual/html_node/Bash-History-Facilities.html
9.1 Bash History Facilities
When the -o history option to the set builtin is enabled (see The Set Builtin), the shell provides access to the command history, the list of commands previously typed.
To get current settings, use set -o command. In interactive shells (with -i option of bash or in usual bashes from login or terminal) it prints history on. When used in scripts (bash -c 'set -o' or when you did ssh machine bash without tty allocation) it is unset: history off.
https://www.gnu.org/software/bash/manual/html_node/Interactive-Shell-Behavior.html
6.3.3 Interactive Shell Behavior - When the shell is running interactively, it changes its behavior in several ways.
Command history (see Bash History Facilities) and history expansion (see History Interaction) are enabled by default. Bash will save the command history to the file named by $HISTFILE when a shell with history enabled exits.
History can be enabled in script with several commands: https://askubuntu.com/questions/546556/how-can-i-use-history-command-in-a-bash-script / https://unix.stackexchange.com/questions/5684/history-command-inside-bash-script - set HISTFILE and (optionally) HISTTIMEFORMAT, enable with set -o history and then use history command.
in bash we can set vi-style line editing interface using set -o vi.
How to set the same in c-shell (tcsh or csh).
I tried set -o vi. but it throws error.
$>set -o vi
set: Variable name must begin with a letter.
Try bindkey -v
See this website
I have no idea how tab completion works, but all of a sudden mine is broken. I don't even know what info to provide other than the use case.
there is a target clean in the makefile.
$ make c<tab> results in
$ make c23:set: command not found
lean
EDIT:
I believe somehow I ruined the set bash built-in since man set says No manual entry for set and which set doesn't report anything. Invoking set on the terminal, however, produces result.
I'm using: GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu) and GNU Make 3.81
thanks to Etan's comment and Aaron's indication of where makefiles are, I managed to debug this.
I ran set -x so I could track what was happening when doing the tab completion. The output of make c<tab> consists mostly of commands from the bash completion file for make, located at /usr/share/bash-completion/completions/make (1).
However, I noticed the an inconsistency between the output and the file. Towards the end, the output said:
+ local mode=--
+ (( COMP_TYPE != 9 ))
++ set +o
++ grep --colour=auto -n -F posix
+ local 'reset=23:set +o posix'
+ set +o posix
Which I identified as corresponding to these lines from the file:
if (( COMP_TYPE != 9 )); then
mode=-d # display-only mode
fi
local reset=$( set +o | grep -F posix ); set +o posix # for <(...)
So the output did a grep --colour=auto -n instead of just grep. Indeed, I had setup this alias for grep
Make worked as soon as I removed the alias.
I hope this helps others debug their problems.
EDIT: I have submitted a bug report here: https://alioth.debian.org/tracker/index.php?func=detail&aid=315108&group_id=100114&atid=413095
Look into /etc/bash_completion, /etc/bash_completion.d and/or /usr/share/bash-completion/completions. You should find a file make which contains the script that will be called when press Tab.
Use the packaging system of your Linux distro to validate the file (or maybe revert to an older version).
Another cause of this could be something in the Makefile which throws the parser in the BASH completion script off the track.
Not trying to get any credits here, but the best solution is actually a bit hidden in the comments...
Please vote this comment up instead of my answer!
easy steps to fix this:
sudo vi /usr/share/bash-completion/completions/make
find the line that has the grep instruction. It should look like this:
local reset=$( set +o | grep -F posix ); set +o posix # for <(...)
add a "\" before the "grep" instruction:
local reset=$( set +o | \grep -F posix ); set +o posix # for <(...)
I have the following variable defined in ~/.vimrc. This works well with XTerm but I can't get it working with GNOME Terminal. Please help.
let g:slimv_client = 'python /home/dumrat/.vim/ftplugin/slimv.py -r "xterm -e sbcl --core /home/dumrat/.sbcl/sbcl.core -s"'
The option -e makes XTerm run the command specified by all of the remaining
command line arguments following -e. Consequently, xterm -e sbcl --core
/home/dumrat/.sbcl/sbcl.core -s opens an XTerm instance running sbcl --core
/home/dumrat/.sbcl/sbcl.core -s command.
GNOME Terminal has the option -x with the same meaning that -e has for
XTerm.1 Thus, change the configuration file, as follows.
let g:slimv_client = 'python /home/dumrat/.vim/ftplugin/slimv.py -r "gnome-terminal -x sbcl --core /home/dumrat/.sbcl/sbcl.core -s"'
1 Note that -e has somewhat different behavior in GNOME
Terminal—the whole command is expected to be in the next argument, while -x
assumes that everything to the end is the command to run.