Uding lldb I defined the following alias : command alias bfn breakpoint set -n %1
Sadly, it does not allow Tab completion as the regular command does. It's a pity because all the time gained in typing the command is lost typing whole identifiers that are sometimes quite complex.
Nevertheless, buit-in aliases allow for completion so I am hoping there's a way to achieve the
same behaviour for user defined aliases.
Are you aware of any solutions to this problem ?
Thansk in advance.
It looks like the problem is with completion in option slots in aliases. The completions work for arguments. I think that’s what you are seeing, not that there’s different behaviors for “internal” and “user” aliases (there isn’t actually such a distinction)…
Every option has its own completer, and lldb isn’t figuring out which slot the positional argument resolves to before handling the completion.
Please file a bug about this with the bugs.llvm.org bug tracker. This should be possible, and would certainly be convenient.
Related
I'm trying to set up copy/paste actions using ctrl+shift+c/p like it is done in GNOME terminal but for urxvt. I didn't find any simple solution - it seems like it always requires scripts, hacks etc which gets me annoyed when it comes to such a basic things. That's why I'm wondering if it is possible to just change/add some entries in ~/.Xresource to move the default behavior from ctrl+alt+c/p to ctrl+shift+c/p - since the former already works as expected.
Also, there is a lot of notions regarding clipboard itself: X calls them "selections" rather than "clipboards"; there are PRIMARY and CLIPBOARD selections; etc. I don't really understand all these subtleties - so feel free to be verbose!
I use Xorg server with i3 WM if it makes sense and rxvt-unicode v9.22 - released: 2016-01-23
Contrary to Thomas' answer, it looks like you can. In the same question he referenced Spencer and Enno both mention that you can bind the native eval extensions in your .Xresources file. This would look like the following:
URxvt.keysym.Shift-Control-V: eval:paste_clipboard
URxvt.keysym.Shift-Control-C: eval:selection_to_clipboard
To disable the previous keybindings, you'll also need:
URxvt.keysym.Control-Meta-c: builtin-string:
URxvt.keysym.Control-Meta-v: builtin-string:
You can reload the file with:
xrdb -load .Xresources
You'll need to restart rxvt for the changes to take effect.
short: no, you can't
longer: I pointed out in Rebinding CTRL-ALT-[C|V] to CTRL-SHIFT-[C|V] in URxvt >= 9.20 that the binding for these is essentially hardcoded in urxvt without an easy way to change them (aside from external scripts or modifying the program itself).
In writing a function for fish shell I want to know if a lone wildcard (not part of a bigger expression) was used in the command arguments. Fish does the wildcard expansion before passing arguments to my function, so there is no easy way that I can see to do that, aside from check whether the arguments are the same as the output of ls. The inefficiency of that method makes me sad, though. Is there a better way to do this, without going into fish's source code?
EDIT:
Thanks for the input. Specifically, I am looking to add some functionality like zshell has for warning if there is a * in the arguments of rm. I know that there was an issue opened on GitHub specifically about this but I couldn't find the link again. I have typod, for example, rm * .o instead of rm *.o, and accidentally deleted all my code (... which I brought back from git, but still).
EDIT 2:
Here is the issue on GitHub: https://github.com/fish-shell/fish-shell/issues/1511
No, there's no way for a function to tell where its arguments came from. Maybe if you give more details about what you're really trying to accomplish, we can give another suggestion.
Simple question. I'd like to know how to tell whether the current shell is running as a mc subshell or not. If it is, I'd like to enter a degraded mode without some features mc can't handle.
In particular, I'd like this to
Be as portable as possible
Not rely on anything outside the shell and basic universal external commands.
Though it's not documented in the man page, a quick experiment shows that mc sets two environment variables: $MC_TMPDIR and $MC_SID. (It also sets $HISTCONTROL, but that's not specific to mc; it affects the behavior of bash, and could have been set by something other than mc.)
If you don't want to depend on undocumented features, you can always set an environment variable yourself. For example, in bash:
mc() { MC_IS_RUNNING=1 command mc "$#" ; }
Entering a "degraded mode" is another matter; I'm not sure how you'd do that. I don't know of any way in bash to disable specified features. You could disable selected built-in commands by defining functions that override them. What features do you have in mind?
I would like to add documentation for bash functions so that users can lookup the functions with man. There should be no visible difference between my functions and actual commands.
I know I can do this by overriding man with a function that checks for my own functions. Is there another way?
If you have your man pages created (which is a task in itself) then what you can do is put them somewhere on the system like /usr/local/man (or wherever you like, really), then edit the system-wide $MANPATH variable to include that location. Then the man pages will be available.
Real shell functions are not documented by individual man pages but by the help builtin command. You would have to override that. But even I would not look there for information.
Just generate normal man pages and throw them into /usr/local/man/manX or /usr/local/share/man/manX - whatever your distribution already provides. Check /etc/manpath.config that this directory is already mentioned there. That way no one must fiddle in their startup files with the MANPATH environment variable.
Each manpage should also contain a clearly visible section explaining, that this is a function and not a command and what the difference is.
After that the social part kicks in: Tell everyone at every occasion about that documetation. By every I mean every, not only suitable. :-)
I have been spending a lot of time in the shell lately and I'm wondering how the tab autocomplete works. What's the mechanism behind it? How does the bash know the contents of every directory?
There are two parts to the autocompletion:
The readline library, as already mentioned by fixje, manages the command line editing, and calls back to bash when tab is pressed, to enable completion. Bash then gives (see next point) a list of possible completions, and readline inserts as much characters as are identified unambiguously by the characters already typed in. (You can configure the readline library quite much, see the section Command line editing of the Bash manual for details.)
Bash itself has the built-in complete to define a completion mechanism for individual commands. If for the current command nothing is defined, it used completion by file name (using opendir/readdir, as Ignacio said).
The part to define your own completions is described in the section Programmable Completion. In short, with
complete «options» «command» you define the completion for some command. For example complete -u su says
when completing an argument for the su command, search for users of the current system.
If this is more complicated than the
normal options can cover (e.g. different completions depending on argument index, or depending on previous arguments),
you can use -F function, which will then invoke a shell function to generate the list of possible completions.
(This is used for example for the git completion, which is very complicated, depending on subcommand and sometimes
on options given, and using sometimes names of branches (which are nothing bash knows about).
You can list the existing completions defined in your current bash environment using simply complete, to have an impression on what is possible. If you have the bash-completion package installed (or however it is named on your system), completions for a lot of commands are installed, and as Wrikken said, /etc/bash_completion contains a bash script which is then often executed at shell startup to configure this. Additional custom completion scripts may be placed in /etc/bash_completion.d; those are all sourced from /etc/bash_completion.
If you are interested in the basics:
Bash uses readline which features history and basic completion. You could inspect the source if you want to get a detailed understanding.
Furthermore, you can use readline to build your own CLI interfaces with completion