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': ******
Related
I'm the uninformed user. I want to use mercurial for my personal use in terms of writing code and writing papers and have every change be accessible. I'm not a programmer by trade, I run a lot of matlab code and that's it as far as programming experience goes. I've installed the TortoiseHg with Windows Explorer "shell" integration all-in-one package. I already have python 2.7 installed too.
Next I went to this tutorial: https://www.mercurial-scm.org/wiki/TutorialInstall and I got lost right away. They say the mercurial program is called hg, so I type so in the search function and it comes up, I open it and a quick command window opens up and closes in a fraction of a second and that's it, nothing else happens. I read a bit further into the tutorial and they say that you have to type hg in the prompt. I tried windows powershell and this did work but I don't know if I was supposed to be doing this from within some hg prompt or something.
I went to the next step of the tutorial and they go through the steps of making a repository. I blindly typed the commands they have setup and it worked until I typed "ls -a" saying that it's not a recognized cmdlet.
I don't know what I'm doing and I need a better resource that helps me get this set up and running as I don't understand why even opening "hg" does apparently nothing or if even I should be using powershell for the tutorial.
Mercurial is mainly used by people who are programmers by trade...so all the tutorials are written for programmers, and therefore assume a certain understanding of how command line applications work.
I suspect you're not that familiar with the command line, so first of all, I second user694733's comment:
For a beginner, the TortoiseHG GUI is way easier to get started.
(and they have excellent documentation as well)
Anyway, here's why the command line didn't work like you expected:
hg is a command line application. When you directly start it from Windows (which you did by typing hg in the Windows start menu), it behaves like you described: it pops up and immediately disappears. You need it to start from the Windows command line instead.
There are two different command lines in Windows:
a) Windows PowerShell, which you already used
b) the "classic" Windows command line, which you can open by typing cmd into the search box in the Windows start menu
There's no special "hg prompt", it's just that you're supposed to run hg in one of the two command line interfaces I listed above. It doesn't matter which one you use - hg behaves the same in both.
it worked until I typed "ls -a" saying that it's not a recognized cmdlet.
Mercurial does not only work on Windows, but on other operating systems as well (Linux and Mac OS, for example).
The hg commands are the same everywhere, but everything else is different depending on your operating system. For example, ls is the Linux command to list the content of a directory. In Windows, it's dir instead.
Most, if not all, of the Mercurial developers don't use Windows, so their tutorials are not written with Windows in mind.
You should really start with TortoiseHG, as mentioned above (its documentation is Windows friendly, too) or if you really want to use the command line, I'd suggest a different tutorial, Hg Init, which was written by a Windows guy (Joel Spolsky, the CEO of Stack Exchange, the company that runs Stack Overflow).
my goal: to create a suite of scripts that do some common system tasks, which include these
copy/move/list/search/grep files
watch/start/stop processes
run queries against Oracle via sqlplus
i grew accustomed to using Cygwin/bash to ease my life at work, and frankly speaking, i don't want to move away from bash language and start learning PowerShell, for example - so i started searching for a way to run bash scripts on Windows, ... preferably something alternative to Cygwin.
the truth is that i am still not pleased with Cygwin installation, and the fact that there is no simple way around it, that it is targeting more or less expert users, and there are a number of things that might pop up during the installation. i mean. what i am trying to do now is to write a suite of scripts that will target someone less expert than me (and i am in no way a real expert) - in most cases some kind of an administrator who doesn't want to know the script details.
i am thinking that this user will also want to be able to run these scripts on another machine, and i want to be able to explain him/her how to do it, without just saying, call the support, and, me, eventually (so that we can install cygwin on another machine etc etc.)
i tried MinGW(msys) but it also needs manual steps to set things up - i mean, these manual steps have become something of a de facto standard in these Windows ports (sorry, maybe i have a mood for bragging). win-bash looked like it could be a solution, but i ended up trashing it too, because of the old bash version, and its inability to do things i was able to do in cygwin - specifically
here documents
things like "cmd /C dir *" (don't know why) - and yes, i do cmd /C dir in cases i am in some kind of shared network folder with thousands of files, and ls is significantly slower than dir
my questions at last:
am i doomed to use PowerShell? i guess i will, reluctantly, if i have to
is there a simple pre-packaged "slim" cygwin installation.. or, portable cygwin, even better? there is a cygwin-portable project on sourceforge, but it's not that doesn't need those manual steps, again, apparently - is there a way to automate those steps, perhaps? and if there is, i wonder why somebody hasn't done it already? - and then, would it be possible to call bash scripts from Windows command prompt using a simple command like "bash somescript.sh"?
thanks for your attention.
As mentioned here, the Cygwin installation can totally be scripted and parametrized to ran in a silently and automatic mode.
If you define the minimal list of cygwin packages you need, just use a little .bat script that call the cygmin setup executable like this
setup.exe --packages=list_of_packages_you_need --quiet-mode
If you wrap the cygwin install process, it should be tolerable for a less technical user.
The cygwin install can be streamlined using command-line args;
http://sources.redhat.com/ml/cygwin-apps/2003-03/msg00526.html
You can also automate the install of most cygwin packages through cyg-apt.
I haven't verified this but I suspect that msys implements a *nix look alike by creating windows executable versions of system commands. All of the common commands have an executable on my install of msys. If that is true then it should be possible to use them separate from a complete install.
Try copying "bash.exe", "cp.exe", etc. from the msys bin directory to a machine/vm that does not have an msys install and see if it works. You may need to copy some dll's or shared libraries as well. A windows dependency checker program would show which dll's an executable is using.
You could package up the stuff you use and make a simple installer or just copy the files with your scripts.
Take a look at MKS Toolkit. Unlike Cygwin, it can live within the Windows world. Files end in CR/LF like Windows files, and you don't have that /cygdrive/c stuff. Naked drive letters work fine in MKS Toolkit.
A few caveats:
I haven't used MKS Toolkit in a long time. See following reason.
MKS Toolkit is (sit down for this) $600 per license. Ouch! That's why I use Cygwin even though I don't think it's as good or works as well.
It's Kornshell based and not Bash (although this may be a bit different). Kornshell and BASH are 95% alike. However, that last 5% gets you. I actually like Kornshell better than BASH in many respects. Kornshell has the print statement which is way superior than the echo statement. Variable names don't disappear in blocks. You can easily do double loops because almost all the commands can take unit numbers of input and output. However, Kornshell doesn't have those neat escape characters in the prompt, and it's hard to find the exit status of a command in the middle of the pipeline.
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
It seems random: after some amount of time / usage of any console I use on Windows Vista, I lose the ability to use the command-line history (or command buffer, if you prefer...), and hitting the up or down arrow no longer does anything at all, meaning there are essentially 0 items available in the history.
I've seen this behavior in Cygwin, CMD, and PowerShell.
Sometimes this behavior applies to processes running inside the console - Python, MySQL client, etc.
Is this an inherent problem in Windows? A setting somewhere? Are there other consoles that don't have this problem?
ps - if you think this is non-programming related, please see other questions regarding programming tools, for instance, nearly anything tagged "eclipse" which deal with how to use the IDE rather than programming for it.
Two ways, I think.
1) Far Manager is a good choice for a shell. Even if you don't need it's all power (file/archive management, editor, huge number of plugins, macros), you can use it as a wrapper/executor for cmd, tcc, sh or any other program, shell or command processor.
For example
take 3 files from distrib (Far2 or Far3): far.exe, fareng.lng and (optionally) fareng.hlp
run "far.exe /w", press Ctrl+B Ctrl+O
type any command in command line: dir, set, notepad, putty, an so on...
History will be preserved between sessions, you may access it by Alt+F8 (press Ctrl+Alt+F to switch history into filter mode).
Far 2.0 stores history (and settings) in the registry.
Far 3.0 stores history in SQLite database, and may be portable.
Also, Far can autocomplete commands from history or files/paths from disk. And there is plugin (YAC) which can autocomplete from aliases and so on...
2) I have found recently interesting project: Clink - Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe
Powerful Bash-like line editing from GNU's Readline library. Read more on Readline's keyboard shortcuts.
Superior path completion (TAB).
Paste from clipboard (Ctrl-V).
Support for the completion of executables/commands, and environment variables.
Undo/Redo (Ctrl-_ or Ctrl-X, Ctrl-U)
Improved command line history.
Persists across sessions.
Searchable (Ctrl-R and Ctrl-S).
History expansion (e.g. !!, !, and !$).
Scriptable completion using Lua.
It seems a young but budding project, so I had created an option for use it in my Console Emulator.
There's a maximum size of history buffer in a windows "DOS box" -- Upper left icon, right click, select properties and you'll see the Command History has a buffer size of 50 by default.
Check your Scroll Lock key.
DOH! I hit mine by accident so that up and down arrow just scrolled the window.
In PowerShell you can control the maximum size of history via the MaximumHistoryCount automatic variable (default is 64)
PS > $MaximumHistoryCount
I have encountered this issue for years. Mostly with python used from the command line in a bash shell. After some experimentation today when this re-occurred for the 1000th time (more or less) I was able to fix the issue by setting the Command History for the shell to have buffer size of 999 and Number of Buffers to 999 (I picked the largest possible setting for each, it's possible any setting would have worked other than what I was prior, which was 50/50). To access the Command history, right click in in the upper left corner of the shell window, select Properties, then the Options tab. I'm not sure the ramifications of these settings to performance of the shell, but thus far nothing else seems affected and command line history is once again working for me in the same shell it previously wasn't working in. I realize this answer is similar to the answer by steve-gilham, but perhaps gives a bit more background.
Admittedly, my answer involves 1 experiment that worked.
All history in console is provided by Doskey. It also is always available for all character-based, interactive programs (such as program debuggers or file transfer programs), and maintains a command history buffer and macros for each program that it starts.
In DOS era, one can remember softwares that after execution cleared the history. I'm not sure they were bugs, expected behavior, or the mix of two. But some Doskey bugs were know as you can see in the end of this link.
I suggest anyone who get this problem to try Doskey command options and see if (s)he can correct it.
I've never experienced this, but I wonder if pressing the key combination ALT+F7, which clears command history according to DOSKEY /?, might be the cause.
If "suddenly" all history is gone, maybe a new cmd-shell starts?
Test:
C:\Users\Guest\>doskey /history
…long history…
C:\Users\Guest\>cmd
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Guest\>doskey /history
…no history…
C:\Users\Guest\>exit
C:\Users\Guest\>doskey /history
…old long history…
Of cause in this example you'l see the new cmd-Start but if you try out this:
doskey /history
…history list…
cmd echo /k
doskey /history
…no list !
You don't see
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
But a new CMD-Shell was started.
So "exit" may help in this case!
This happened to me when I'm in a Rez environment on Windows 10.
As per #user1769064 's answer above setting the buffers to 999 and restarting the shell with a new environment the issue went away. There's probably a lower number than 999 with which it works as well, but haven't tried it.
right-click on the top-left corner of the Windows Command Prompt on the C:\ icon.
Choose Properties
In the Options tab, find Command History setting
Change the Buffer size to 999
Close the terminal and relaunch it again
AngeFtp? EFS?
Is there a better option?
Is the preferred option built-in?
If so, how do I turn it on?
If not, where do I download it?
I tried with AngeFtp, just by doing find-file using a filespec like
/name#server:/directory
and it prompts me for a password, then does the login to the FTP server and gets the contents - it takes a while - but when it finishes, I don't get or see a dired buffer. I just get a blank buffer with a weird name.
Tramp is the modern replacement for ange-ftp.
The short version is, you specify a file like "/myusername#host:path/to/file". Works like a charm.
View the linked documentation for installation instructions, though it might already be installed if you have a fairly new installation of emacs. Also, there are several questions related to tramp and remote development with emacs on SO
I just use C-x C-f or C-x C-d, with the remote-file format /host:/path/to/my/dir/. And I customize tramp-default-method to "ftp". Works like a charm. When it opens the connection for the first time (only), it prompts for the password.