appcmd set config /section:applicationPools /[name='xxx - yyy'].processModel.idleTimeout:0.00:00:00
When I run this command, instead of receiving a validation message or an error message, the command goes "idle".
It actually just display the caret and I can write text, or wathever... until I CTRL+Break the command.
I tried waiting for 10 minutes but nothing else ever happens.
It's really weird, the command seems correct :S
Do you know what I possibly could be doing wrong?
Apparently when there is a space in the application pool's name, you have to put the "modification parameters" in quote.
So the command should actually be like this:
appcmd set config /section:applicationPools "/[name='xxx - yyy'].processModel.idleTimeout:0.00:00:00"
It really gets me to wonder why the simple quotes aren't useful enough.
Related
I'm trying to generate a key for my computer, but I notice that when I try running the command that I see on GitHub.com, nothing happens, and I only get a prompt. I'm wondering what could be happening? Advice is appreciated, thanks!
I tried searching up how to generate an SSH key, and it seems that I'm supposed to be getting a different output. I tried going into different directories but got the same issue.
Edit: Adding text output, since I can't seem to produce an image.
[username]$ ssh-keygen -t ed25519 -C “[Github email]"
(Output): ">"
One of your quote symbols is the wrong type of quote symbol - specifically, it's U+201C LEFT DOUBLE QUOTATION MARK. Re-type the command - it was probably messed up by copying it from somewhere.
If your shell prompts you with a >, that means you are not done entering your command yet. Try typing something simple like
echo "test
Bash will display a > and wait for you to finish the command. In this case it's because you've opened a quote (the last character in your command) and not yet closed it.
Assume I want to invoke a tool with a lot of options, like:
$ somescript --option1 --option2 --option3 --option4 --option5 whatever even more stuff
But the width of the terminal doesn't allow to have that thing on a "single line".
That alone isn't a problem, but with fish, there is a problem with scrolling.
When I enter that extra-wide command, at some point, there will be a line break:
$ somescript --option1 --option2 --option3 --option4 --option5
whatever even more stuff
All fine so far. While typing such a lengthy command, I can scroll forth and back at any point. Works as expected. So, assume I entered the command, made a mistake, and now want to remove --option4.
The normal thing: use "arrow up" to get to that command in the history, to then use "arrow left" to scroll within the command. And now something weird happens.
Everything is fine while the cursor is within the second line. But when the cursor moves to the first line ... after 3 to 5 more "arrow left" strokes, the cursor moves UP another line. Then it sits above the first line of the command. There is also a vertical jump of a few characters.
In other words: as soon as a command is longer than the width of the terminal, I am unable to scroll into the first line reliably. The cursor shows up somewhere, and it is really hard to guess where it really sits at any moment. Which makes it almost impossible to edit anything in that first line.
This is on MacOs, using iterm 3.2.9 and fish version 3.0.2 installed via brew.
Wrote up defect 6014 on github. Outcome is rather frustrating.
The problem is: the Mac terminal(s) all handle certain unicode characters the wrong way. "Normally" that isn't a problem, but when you use one of those fish prompts that give you the git status (like AcidHub which is my favorite) ... fish can't compute/determine the exact line width, and there you go.
So, basically, when using fish on MacOs, option space is limited to:
use the defaults, which (when using special prompts, like AcidHub will lead to scrolling issues)
adapt the fish prompt accordingly (in my case, I replaced all special unicode chars with something simpler). It doesn't look that great, but scrolling simply works again.
And a completely different and unexpected solution to the problem: I am using iterm2 on my Mac, and iterm2 just added a "status bar" section. That can be easily configured, and of course, it already has a status bar component that tells you about git status.
Thus my solution: I changed the fish prompt to just give the PWD, and all the other things that the AcidHub prompt has to offer, are now "iterm2 status bar" components!
Ok I'm having trouble and google isn't helping, so I thought I'd come to you geniuses. I'm using Powershell and posh-git, and it keeps doing something that I'm sure I can exit out of with a magic command, I just don't know it yet.
Basically, when I run git diff (or something else with a long result), it will only give me a screen's worth of information, and end the screen with a colon
:
And if I keep pressing Enter it will add more to the screen til it is done showing everything for that command, and shows
<END>
But now what? How do I get out of this and back to calling commands? Enter, Esc and the other things I thought to try are not helping. I'm sure this must be a simple thing, but I don't know how to explain to Google what I want.
Anyone know?
if you do a git config -l you may see some relevant entries like:
core.pager='less'
pager.diff=false
pager.log=true
You can enable or disable the pager for different commands, or set a different pager. https://www.kernel.org/pub/software/scm/git/docs/git-config.html has the details, check out the core.pager section and pager.<cmd> sections for specifics.
If you're using 'less' as your pager, hit 'h' at that : prompt to get lots of details about what you can do there, and as pointed out by others, q, Q, or ZZ will get you back to the command line.
You can terminate the current command using CTRL+C. Is that what you're asking?
I'm trying to use the date command to output today's date in the format %d.%m.%y-%H:%M:%S. Obviously I just do that like this:
date +%d.%m.%y-%H:%M:%S
This works fine in bash and I get the output I'd expect, but when I do this in zsh I get what I'd expect prefixed by '7m', for example
7m07.09.12-16:49:37
instead of
07.09.12-16:49:37
I also get an alert from my terminal. This is caused by the %S for seconds, because when I take that off the end of the command I don't get the '7m' (but obviously I'm missing the seconds off the end of the date).
Can anyone explain why this happens?
EDIT: extra information: I'm on OS X 10.8 and with zsh 4.3.11, oh-my-zsh installed
One workaround is to wrap the code around echo $(...). It produces the right output and was acceptable for me. Your original command would look like:
echo $(date +%d.%m.%y-%H:%M:%S)
I had the same issue, and could solve it by commenting out line 12 of .oh-my-zsh/lib/termsupport.zsh as suggested at https://github.com/robbyrussell/oh-my-zsh/issues/521
I am sure that you have copied CTRL chars somewhere.
7m is a control code to reset.
Look for ^[[7m when you are editing.
If you just want the time then ZSH has a nice %*
if you want date and time then try
RPS1='%W %*'
If you like it, then put it in PS1 or wherever you like.
I'm writing a script in Python 2.7 exploring the use of the multithreading and Queue modules. the script just defines two functions, one of which will be started in a thread instance to fill a Queue, and a second one which will be started in a second thread instance to pull something off the Queue. However, I cannot even get this script to execute, as it chokes on one of the function definitions even before it executes. The code snippet with the problem is:
def listenThread(counter):
while queue.empty() != True:
try:
outcome = queue.get()
print outcome
counter -=1
print counter
except:
return 'queue.get() command loop failing.'
The error message I am getting is:
$ python threading-and-queue-test.py
File "threading-and-queue-test.py", line 34
except:
^
IndentationError: unindent does not match any outer indentation level
$
I've searched SO and checked the docs for correct formation of the try-except construct, and it seems OK. I had earlier versions of the code (without the try-except ) working, so I am getting suspicious about the text editor, TextWrangler v4.0.1.
Can anyone suggest a debug approach or code correction?
Thanks!
Red
As you have already suspected, it is most likely an indentation error. Your text editor is probably mixing the use of tabs and spaces. Replace all tabs with spaces (or vice versa though the standard in python is 4 spaces) and you should see the error disappear.
For those who find this question later like I did it's easy to fix TextWrangler's settings and stop this issue altogether; Go to "Preferences" -> "Editor Defaults" -> "Auto-expand tabs" then set tabs to 4 spaces. Restart TextWrangler for changes to take affect. For existing documents that continue giving you a problem read this.