tl;dr: How can I modify my host (%m in prompt) such that it will be modified regardless of theme?
On my work computer, I cannot change my hostname. I have edited a (oh-my-)zsh theme to replace the host (%m) when i'm on myridiculoushostname.evil.corp with something shorter. I'd like to try out more (oh-my-)zsh themes (e.g. by setting my theme to random), but I'd like to somehow modify just the host component of the prompt in all of them.
Hacky Answer: do all of your magic in your root .zshrc, and do it on the shell variable HOST. For example, adding HOST="test" to your .zshrc will make %m and %M both read test. The reason I called this hacky is HOST is a general shell variable, and its possible other applications and scripts will check it's value.
'Right' Answer: Set your own prompt in your root .zshrc, and handle the hostname magic the exact same way you handle it right now. This has the downside that the prompt for each theme isn't shown, but AFAIK there's no way to directly modify what %m evals to.
Answer so Scary I almost Didn't write it: At the end of your zshrc, use awk to do a string replace on the PROMPT variable. You can simply map %m to a string of your choosing, effectively doing the prompt substitution for zsh. This will work no matter what theme you use, but it just seems obtuse.
e.g.: PROMPT=$(echo $PROMPT | sed 's/%m/test123/')
Related
I'm trying to understand how the shell handles redirection a little bit better. My understanding is that the syntax "n<" means to redirect the file descriptor given by "n."
The command I'm struggling to understand is
echo "first" > test; echo "second" 1< test
What I thought would happen is that the file "test" would be overwritten with the text "first"; then, when the second command executed, 1--i.e., stdout--would be redirected to test.
What actually happens is the following:
Nothing writes to terminal, so stdout was redirected somewhere;
When I open "test," what's written is "first" rather than "second," so I didn't overwrite "test."
Can anyone explain what's going on? Is it that stdout is being redirected to test but in "readonly" mode or something like that? I can't find any reference to using 1< in a script elsewhere (since, admittedly, it seems like a strange thing to do).
The shell redirection 1<foo makes FD 1, aka stdout -- normally an output descriptor -- connected to a read-only handle on file foo.
Thus, when echo tries to write to that read-only handle, it will fail; in most reasonable shells, this will also write an error message to stderr.
In this context, that code serves no purpose, and is simply a bug; you'd need to have a program that tried to read from FD 1 (perhaps assuming that to be a connection to the current terminal) for it to be meaningful. (That said, any program that did this would be buggy itself; reads should be done, if not through FD 0, from a handle direct on /dev/tty).
I've been through the subreddit and the SO tag as well as a couple of pages of multiple phrasings of a Google search, and I can't find any threads/topics/pages that address this, so here goes:
I want the prefix key in tmux to always 'activate' the prefix in tmux. Let me explain what I mean - from the man page:
tmux may be controlled from an attached client by using a key combination of a prefix key, `C-b' (Ctrl-b) by default, followed by a command key.
The default command key bindings are:
C-b
Send the prefix key (C-b) through to the application.
I don't have 'send-prefix' in my tmux.conf set to send the prefix combination to the application when pressed twice, but the result seems to be that the prefix now acts as a 'toggle'. Press it once, and the next key is interpreted as a command. Press it twice and the next key is sent directly to the application. For example:
C-b, C-Up results in my pane being resized up by one cell, but
C-b, C-b, C-Up results in ctrl + up being sent to my terminal window.
I would like to make it so regardless of how many times the prefix is pressed, the next key pressed is always interpreted as a command (i.e. the two keystroke sequences above to give the same result).
Thanks in advance!
If you're wondering why I want this, suffice to say it has to do with a very complex tmux.conf file and the repeatable flag on a lot, but not nearly all, of my key bindings. I'm so accustomed to having to press the prefix immediately before the non-repeatable bindings that I always hit it, even if I've just finished using a repeatable command. This looks like a 'second' press of the prefix to tmux, which makes sends my command key to the terminal. Edge case, I know, but if it is possible to turn this behavior off it would save me a ton of mistaken keystrokes!
This should do the trick:
bind-key C-b switch-client -Tprefix
It makes more sense if you think of the prefix not as a special key, but simply one bound in the root table that also calls switch-client -T:
# Equivalent to 'set-option -g prefix C-b'?
bind-key -Troot C-b switch-client -Tprefix
I'm using QSettings to parse a ini-format file without a group, like this one:
msg=45
id=69
So far so good, but when I try to write a new key, it goes like this:
[General]
new=100
msg=45
id=69
My goal is to have something like this:
msg=45
id=69
new=100
This is my code fro writing:
QSettings settings(m_rcFile, QSettings::IniFormat);
settings.setValue("new", num);
I know most ini files have group/key/value but since QSetings can read them without a group I though that it can do the same for writing. Any ideas?
Seems consistent with the documentation at least, which says
if you save a top-level setting (a key with no slashes in it, e.g., "someKey"), it will appear in the INI file's "General" section.
Just below it says
Following the philosophy that we should be liberal in what we accept and conservative in what we generate, QSettings will [...]
which, while addressing a different quirk, could explain why QSettings can read values from a non-section, but refuses to write there.
Bottom line is that you need a different approach (another library or a low-level class like QFile/QTextStream) to write those values if you really cannot put them in a section.
I am after the one which is most used. A number of ones I have come across are:
CurDir
Environment.CurrentDirectory()
AppDomain.CurrentDomain.BaseDirectory
Application.StartupPath (this one doesn't work for me, missing a library?)
I am using it to save a file, for argument sake, "test.txt"
I may be oversimplifying, but if you want to save something in the folder where your app is running, just omit the path.
call MyObj.SaveTo("test.txt")
I'm trying to simply save a file. However, I need a filename entered without a suffix to automatically get a default suffix (which setDefaultSuffix() does).
I'd rather not completely lose the native save dialog just for this. exec() is not overloaded from QDialog, so it totally bypasses the native hook (ignoring the DontUseNativeDialog option even if it's false).
If I disable the file overwrite warning and append the default suffix myself after the function returns, then I'd be re-opening the dialog if the user did not want to overwrite... and that's just ugly.
Is there some signal I can catch and quickly inject the default suffix if it's not there? I'm guessing not, since it's a native dialog.
Is there something I'm doing wrong with the filter? I only have one filter choice. It should use that extension.
This seems pretty lame. Launching the save dialog and simply typing "test" should never result in an extensionless file. "test.", yes. "test" no way. That'll really confuse the users when they hit Load and can't see the file they just saved.
I guess the cross-platform part of Qt is giving me lowest common denominator file dialog functionality?
Yes, if you look at the Qt source code it is evident that only the static functions uses native file dialogs. It is not possible to get native dialogs any other way, unfortunately...
Have you tried the filter options in the static functions? [Edit: Oops, noticed that you already have.]
I just tried this myself, for example, and things seem to be fairly reasonable:
QString filter = "Text files (*.txt)";
QString selectedFilter;
QString filename = QFileDialog::getSaveFileName(0, "", "", filter, &selectedFilter);
Entering test in the save dialog returns test.txt.
Entering test. in the save dialog returns test..txt.
Entering test.foo in the save dialog returns test.foo.
These all show the appropriate overwrite dialog if there is already an existing file with that name.
The only way I can get test, without any suffixes, is by surrounding it with quotes ("test"), or by first entering *.* (which will make it display all files) and then entering test. (Although one oddity is that selectedFilter will still contain the filter shown in the dialog, even if it's not used).