I might just be thick this morning but I cannot seem to get html2haml with the -s or --stdin option to work.
Running html2haml or html2haml -s on the command line looks like I get put into some input mode but with no way to escape but ^c. This causes an interrupt and nothing more happens.
You need to use Ctrl+D to send end of file so html2haml knows the input is finished, rather than Ctrl+C which interrupts the process. (These keys are actually the defaults and may vary, but are probably right for you).
Related
I’ve been trying to use the command grep, but without the -R parameter the whole cli goes just idle.
Can someone explain me why?
I assume you're not providing any files at all to search. If that's the case, then grep is reading from stdin (standard input). It's waiting for you to close the input (Ctrl+D), and then it'll search that.
If you want to search files, you need to tell it what files to search. Perhaps you mean to include * in your command?
I have clean install of spacemacs. When I press escape to enter normal mode then immediately press u it will uppercase a word. If I wait a second, it will undo last action.
I'm assuming this is evil-mode or emacs key-chord feature in action. How can I change that behavior?
Spacemacs, particularly the develop branch should just work right out of box without the delay. However, I have found that this delay happens when I am running emacs inside of tmux. You should see if you are trying to run this inside tmux or screen, and if you are, see if this problem happens when you run emacs directly inside a terminal, without a terminal multiplexer.
If tmux is your problem, you can fix this with:
set -s escape-time 0
You'll have to find the equivalent in screen if that is what is happening.
See: https://bitbucket.org/lyro/evil/issue/69/delay-between-esc-or-c-and-modeswitch
Zeroing out my delay as Ho-Sheng Hsiao suggested has served me well, but as Wesley Baugh pointed out, that has the consequence of preventing the use of ALT-key modifiers in your editors.
The Emacs-evil FAQ addresses the problem, but not very succinctly, and without a concrete recommendation.
The Neovim FAQ has a more succinct explanation, and a specific recommendation:
set-option -sg escape-time 10 # millisecond delay
I'm trying to run a tcl script on a Cisco router in GNS3;
SanJose1(tcl)#foreach address {
+>192.168.1.1
+>192.168.1.2
+>172.16.224.5
+>172.16.224.6
+>192.168.72.1
+>172.16.224.2
+>172.16.224.1
+>10.2.1.1
+>10.2.2.1
+>} { ping $address }
When I do this, nothing happens, no pings, no errors, it just returns to the router prompt.
Am I running the code incorrectly? If it's correct then I can look into problems with GNS3
Thanks!
The foreach, as you write it in your question, appears correct. (If there was one more argument, you'd get the message from the question title, but your code sample shouldn't generate that.) It's more likely that the ping you are calling doesn't write anything visible, and instead just produces the result as a string. That's pretty common with Tcl code. I'd expect something like this to work, assuming my diagnosis is correct:
foreach address {
192.168.1.1
192.168.1.2
172.16.224.5
172.16.224.6
192.168.72.1
172.16.224.2
172.16.224.1
10.2.1.1
10.2.2.1
} {
puts [ping $address]
}
I've omitted the prompts and added indents and a few more newlines for clarity. If ping is really an external command, use exec ping $address instead (it's considered bad form to rely on the unknown command handling to bring external commands into your code, especially as it is disabled in scripted mode.) With an external command, you might also want to pass the -c option with a number so as to limit the number of requests used to a fairly small number, perhaps:
puts [exec ping -c 5 $address]
Be aware that the set of commands supported by a Tcl interpreter can be changed completely (by design) and that the commands listed in the documentation are really just a pre-supplied standard library. When Tcl is embedded in an environment like a router, it is quite possible that things have been changed around a fair bit. (It's not like it's hard for the router vendor to do it.) That means that surprising differences in commands most certainly can occur, and that you should check the documentation you've got and proceed with a little thought instead of just blindly trusting what I wrote.
The program that I am trying to run takes the form program_name --arg=/some/path/goes/here, but zsh cannot perform tab completion on that path when it is in the argument flag. I end up having to type progra<TAB> /so<TAB>/pa<TAB>... to complete the path and then go back to add the --arg= part of the command. Is there a more efficient way to go about doing this?
It's likely that zsh is still trying to do file completion in your situation, it's just considering the --arg= to be the initial part of the file name causing it to not find any matches. Since there aren't any universal rules for how commands will interpret their arguments the safest option is for the shell to not make any assumptions about those arguments.
Many commands which use that type of syntax will work the same if you use a space rather than the = sign, such as program_name --arg /some/path/goes/here. Since that would be a separate argument the shell should be able to do file completion without issues.
Depending on how you have zsh configured, it may also work to use setopt MAGIC_EQUAL_SUBST. I normally have that option set and get the behavior that you are looking for, but get the behavior that you currently experience if I unset that option. But, if I use zsh -f to skip loading my configuration just enabling that option isn't sufficient so there is apparently something else in my config that was necessary, possibly just the enabling of the completion system which you would likely have done already. There could be cases where this would result in undesirable behavior, but I haven't run into any in the many years that I've been using zsh with that option set.
A more complicated option would be to write a completion function for that command which tells zsh that that option takes a file name as the argument.
I am implementing my own shell. But to supprt for command history, I need to use monitor up/down arrow key as in standard shells. Please tell me how to handle arrow keys as input or does these keys generate signals? Please elaborate.
Arrows and other special keys send you special strings that depend on the terminal being used or emulated. To deal with this most simply, you could use a library such as termcap. Even simpler, given your stated purpose (command history support), would be to use readline, which basically does it for you (and lets the user customize aspects of their preferred mode of working across the many applications that link to the same library).
It depends on how gnarly you're expected to go. Worse case, you're writing the keyboard interrupt handler. Best case, something like readline.
Check with your prof for direction here. Also check your course materials to see if the prof has given links/examples regarding this.
Does the assignment specifically say you need to have a "cursor key driven" command history?
Simple option is to mimic the shells fc e.g.
$ ls
... file listing ...
$ fc -l
1 ls
2 fc -l
$ fc -r 1
... file listing ...
and (while I'm presenting established ideas as my own, might as well go all the way) to be able to edit the command line you could use
fc -e start end
to write the history from start to end into a file, launch an editor and then execute the resulting file as a script. This way your shell is not using a library, but launching commands and executing scripts, which is what shells are supposed to do anyway.