I'm trying to push a rails app to my remote Heroku repository from a MacBook Pro using the Bash Terminal.
The remote repository address contains numeric characters which are stripped out as soon as I copy/paste "git#heroku.com:app-name-[numbers].git". If I try to type the numbers in manually, the comp just beeps.
Really stuck on this one!
You've got a terminal setup problem. First thing to try is simply to close down the terminal and restart; that'll be a fresh session.
If that doesn't work, carefully type the following
stty sane^J
or
^Jreset^J
to set it to something normal.
It sounds as if you're getting characters echoed at least, so that may be easy. The ^J characters are LINEFEED, which is the actual ASCII character used for newline in UNIX-based systems.
Related
After clearing a Mac terminal (via Command K, or the "Clear All" command under the edit menu), is there a way to easily restore the previously cleared text?
Periodically, when I run a long process on a Mac Terminal (such as a suite of unit tests) I prefer to clear the terminal. I do this so when I'm scrolling up to look over the results of the process, I can focus ONLY on the results of that process and not other commands I've recently run. (Such as, say, a different suite of tests)
But, sometimes I do eventually want to go back and look over the previous suit of tests.
Is there a way to restore previous terminal text?
The terminal is not going to help with restoring the text. It is gone.
If you anticipate wanting to review the text, you could (in a more or less transparent manner—not interfering with your work) run your session in script. That records everything sent to the terminal (including escape sequences for vi).
If your use of the terminal is largely just cat'ing files or watching logs, then the resulting typescript file is usable with less -R. It does not work well with cursor-movement, but for those, I use slowcat or similar filters to slowly cat a file, etc. For best results, the terminal emulator interprets escape sequences reliably.
When running the tests why not redirect the output to a file? This keeps your terminal clear and you can cat (or tail or more or less) that file to see only the results of that process. Another advantage is you can keep these log files around for future reference if needed.
when I try to install something over Putty, it looks like this:
so really buggy :).
Has anyone a suggestion for this?
It's probably something to do with UTF-8 handling on different terminal types.
You could try this solution I found on linux.debian.user:
What release of PuTTY are you using? I'm using PuTTY 0.63, which is
the latest release. In this version, the default value for the terminal
type string is xterm. At least it is for me. I have to explicitly change
it to putty, even after setting the remote character set to UTF-8. Make
sure the terminal type string is all lower case. Terminal type strings
are case sensitive. They have to match the terminal type definition in
ncurses. The putty terminal type definition in ncurses can be found in
/usr/share/terminfo/p. You can also try a terminal type string of
xterm-utf8. This terminal type definition in ncurses is found in
/usr/share/terminfo/x. The latest version of PuTTY can be downloaded
here:
http://www.chiark.greenend.org.uk/~sgtatham/putty
https://groups.google.com/forum/#!topic/linux.debian.user/Yy-kQu1RC44
It's indirectly related to UTF-8: the PuTTY developers chose to ignore VT100 line-drawing control sequences when UTF-8 encoding is used. Doing that requires any application that uses line-drawing to do some workaround.
You can work around this by one of these methods:
setting the NCURSES_NO_UTF8_ACS environment variable, as noted in the manual page, or
using a correct terminal description such as putty, which happens to have a special capability U8 defined, telling ncurses the same thing as the environment variable.
I want to write some pretty, special characters taken from Web in my Shell Console with echo command. I want to write, for example, ▲ character, but it shows me ��� character. How can I solve the problem? Thanks!
I am using Ubuntu 64 bit also. You should check your terminal type and what kind of character-set does it supports. Take a look at this
and this
You need to make sure you character sets match and that you are using the correct terminal emulation. This can be set on both the Linux side or using your terminal client software.
e.g. ANSI, VT100, Linux
Character sets like UTF-8 does include symbols.
On the rare occasion that I have to use a windows command prompt rather than bash, it drives me nuts that tab completion doesn't add a slash to the end of directory names. Is there a setting or script that I can run to force the full completion?
The answer these days is PowerShell. It is superset of the windows command line. It has many of the Linux commands. It has an object-based pipeline and has full access to the .NET framework from the command line.
And it adds a trailing slash when using tab to expand a directory name.
No there is no such setting. Your best bet is to use bash through cygwin but I expect you already knew that bit.
this is quite an old thread but I thought it might still be helpful for others.
I could not find a parameter in Windows to do the trick but I found a executable (GNU, with the Pyton source available) named PyCmd which is an improvement (according to my and my work habits) to regular CMD console.
It can be launched by double click it and it starts a regular console with cmd.exe and it loads itself in the memory to allow a lot of command line editing goodies, among them the same TAB completion behaviour I used to have under Unix Korn Shell (including the Emacs-like keys) with the trailing slashes or back-slaches for directories.
You can find it at:
https://sourceforge.net/projects/pycmd/
The last version is a December 2017 snapshot (but stable for me, could not meet any major trouble compared to the 2013 0.9 stable release), at:
https://sourceforge.net/projects/pycmd/files/pycmd/snapshots/
You can also launch it from an existing console, from CMD.EXE and it starts a sub shell with all its editing goodies. You exit this sub-shell by exit or ^D on an empty line.
Note that I have tested it to under an alternative console like "Hyper" (MIT License, at https://hyper.is/ and https://github.com/zeit/hyper), which I prefer compared to Windows default console, and it works perfectly with it too. I think it's fair to assume that it will work well for other consoles like ConEmu or others, but I did not test it with them.
This answer goes perhaps a little far beyond the original question but -- I hope -- still can provide some help to people like me who like to get the same kind of command-line behaviour as they used to have under Unix Korn shell (possibly Linux bash, I don't know).
Have a nice command line interface to all!
GM
At work, I use Cygwin a lot because it offers me a small oasis in the vast desert of Windows. I inevitably end up running some non-Cygwin programs through the bash shell, such as build scripts (batch files created in-house) and the Subversion CLI binaries (I have the Windows ones installed). 99% of the time, I don't have any problems using this setup. The other 1%, however, causes a strange issue:
With both the build scripts and SVN, most of the time the enter key is interpreted correctly. For instance, I'll kick off the database creation script and it will prompt me for the server name. I type in "localhost" and hit enter. Everything's fine. Then it gets to the end, if there are errors, and prints things out using more. No key that I press is recognized by more. I have to Ctrl-C out of it.
Similarly, if I do a Subversion update, normally everything is fine. In the case where the interactive conflict resolution happens, however, I'll usually type in "tf" for "theirs-full" and hit enter, but nothing happens. I have to Ctrl-C out of it and re-run the update with force merge or use TortoiseSVN in Windows to do it.
Any idea why Cygwin seems to randomly not be passing the enter key through to the programs? I considered that it may have something to do with Unix vs Windows style line endings, so I've tried typing those characters manually, but that doesn't seem to make a difference. Thanks.
Edit: I just had this happen to me again and I realized something. It was SVN prompting me for a password. I typed in the password, which it echoed to the screen (bad) and hit enter... nothing. Hit enter a few more times, the cursor moves, but nothing happens. I hit Ctrl-C and it dumps me back to bash, which then says "bash: [my password]: command not found" followed by a number of new prompts equal to the number of times I hit the enter key. So what happened is the input never made it to SVN, but somehow got read by bash after SVN exited. I thought that may help someone figure out what is going on.
Unfortunately, I think you are hitting one of the issues of Cygwin and windows/dos console apps. See "Console Programs" at http://www.cygwin.com/cygwin-ug-net/using-effectively.html.
It is just a limitation on windows console apps. This behavior is common for the windows myqsl cmd client and svn client, for example.
Here are some things to note -- I've successfully used this approach with both the Windows mysql as well as Windows svn clients:
1) Try making sure you do NOT have "tty" in your CYGWIN environment variable and see if that helps (unset it in My Computer->properties->advanced->Environment Variables and close/restart any cygwin bash prompts).
2) Do not use RXVT -- instead, use the basic Cygwin cmd prompt. This is because RXVT implies "tty" and will break #1 above.
3) Try finding a "native" Cygwin package for the cmds you are having issues with instead of using the Windows cmds. (I haven't found a 1.6 svn client for cygwin yet, though.)
Good luck!
Dustin
The lengthy discussion on the mintty project is here - http://code.google.com/p/mintty/issues/detail?id=56
One solution mentioned which worked in my case (entering authentication passwords for native subversion) is conin - http://code.google.com/p/mintty/downloads/detail?name=conin-0.0.2.zip&can=1&q=label%3ADevelopment
$ conin svn list https://{repo}
Password for 'user': ******