Re: how to embed shell script within a .BAT file
On 11/07/2014 03:26 PM, Nellis, Kenneth wrote: I'm tired of creating pairs of script files: a clickable .BAT file to invoke my shell script and then my shell script to do the actual work. I was wondering if any of the geniuses on this list have come up with a way to embed a shell script inside a clickable .BAT file. Something like this might do. It assumes you know the path to the Cygwin bin directory. Passing in arguments would be a bit more work and would probably be somewhat limited unless you have a small number of possible arguments. FYI, I don't have a Windows system readily available anymore, so this is untested. Shelly.bat: @echo off rem Put Cygwin bin directory into PATH set PATH=C:\cygwin\bin;%PATH% type %0 | sed 0,/^---BASH SCRIPT FOLLOWS---/ d; s/\r*$// | bash goto :eof ---BASH SCRIPT FOLLOWS--- echo $SHELL is alive ^Z -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: git fork failure on pull with a workaround (hopefully a clue for a fix)
On 11/07/2012 01:02 PM, Bill Hoffman wrote: Is there a way to debug this? The first step is to follow the problem reporting guidelines: http://cygwin.com/problems.html Following them may reveal a conflicting cygwin.dll file or something similar in your full path which is interfering with some git subcommand loading properly. Given that a PATH of just /usr/bin works for you, try appending progressively more segments of your original path until the problem reproduces. Once you find a PATH that reliably fails, remove the last added segment as a suspect and continue adding the remaining segments from the original PATH until you are left with a good PATH and a list of suspects. Then go back to the PATH of /usr/bin and append each suspect individually and test again to see if the suspects are the problem alone. Since its also possible that you may be encountering some PATH length limit here, it may also be worthwhile to report the output of the following command: echo $PATH | wc -c Good luck! -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin: how to mount linux FS from cygwin
On 06/28/2012 02:55 PM, Daniel Colascione wrote: On 6/28/12 12:34 PM, ping wrote: I still miss the magic sshfs tool in linux... You can make it happen. In principle, FUSE should work as well in Cygwin as it does under Linux, albeit for Cygwin programs only. It'd just be a matter of writing the glue logic and hooking into Cygwin's VFS internals. You may have more immediate results by using a Windows-native SSHFS implementation. I haven't used Dokan myself, but it appears promising: http://dokan-dev.net/en/ It's basically a FUSE implementation for Windows that includes an SSHFS client. There is also another one that seems related: http://code.google.com/p/win-sshfs/ Assuming you can get one of these to work for you, you'll have the advantage of using it not only with Cygwin programs but native ones as well. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Query about how to get 'full' Cygwin/unix support
On 03/28/2012 03:07 PM, AngusC wrote: Hello I am using cygwin and have copied the core cygwin files to a folder called binarytools on my Windows PC. This folder is first item in path env variable. When I run make it has commands to do a mkdir -p foldername But mkdir -p myfolder creates a folder called -p and also a folder called myfolder??? Why the strange behaviour? How would I get the standard unix behaviour? I believe that mkdir is a builtin function of the cmd shell which you are probably using. If I'm right, then that function will supersede anything in the PATH. That means that you're not using Cygwin's mkdir program in your command which should explain the behavior you see. To work around this, you can either run your commands from within a bash shell rather than cmd or you can explicitly call the program using its absolute path, such as C:\binarytools\bin\mkdir.exe. Maybe just calling mkdir.exe would also work. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On 03/01/2012 01:05 PM, Eric Blake wrote: On 03/01/2012 10:53 AM, Matt Seitz (matseitz) wrote: You don't think that Setup telling the user package xyz requires package xinit might at least tip off some users that running xyz now requires starting an X server? Even if it doesn't reduce the questions, would it at least reduce the problem of users now having to run Setup a second time to download and install the xinit package? While I can't control whether Yaakov adds xinit as a dependency to tcl-tk, I personally wouldn't mind adding xinit as a prereq to gitk and git-gui, since I maintain that package. There's still that annoyance factor that just depending on xinit won't get X running, but at least it will let you download all the bits in one run of setup.exe instead of hitting the FAQ and finding out you have to rerun setup.exe. I don't think I've ever seen it, but does setup.exe support the notion of recommended and/or suggested packages? It seems that the main issue is that xinit is not a hard dependency of these tools/libraries and thus they should not have a hard dependency on xinit defined in the package definition. However, it might make sense to make xinit a recommended dependency that setup.exe could offer to install by default or at least notify the user that they may want to install. Less sophisticated users of setup.exe could select to always install all recommended packages by default (this may be the default setting) while more advanced users may disable that option in order to be more choosy. While this wouldn't help the problem of users needing to actually start the X server before using the dependent tools and libraries, it would at least give them a chance to get what they need in a single pass of running setup.exe rather than needing to run it again and try to select the correct additional packages. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On 02/24/2012 08:25 AM, Fergus wrote: Previously bin/wish was a link to wish84.exe (from memory). Recently it was upgraded to wish 8.5.exe. Now, unless X is also running, wish fails with $ wish % Application initialization failed: no display name and no $DISPLAY environment variable I'm not quite certain which recently upgraded package led to this: tcl-tk or tcltk or ... Have I identified a real glitch and if so can this problem be addressed? The tcltk libraries now require a running X server in order to display graphics. This is recent and more importantly intentional according to what I've read on this list, so there is nothing to address. :-) -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Documentation on -mno-cygwin Accuracy
On 02/08/2012 09:49 AM, Jesse Ziser wrote: On 2/7/2012 11:58 PM, Christopher Faylor wrote: On Tue, Feb 07, 2012 at 05:14:59PM -0600, Jesse Ziser wrote: If you really want Mingw (a free compiler and development environment for Windows), maybe what you should do is just download and install Mingw, and use that, instead of doing it through the Cygwin compiler using a barely-supported option. (Then you should get help with any problems you have over at Mingw's website instead of here.) The MinGW cross-compiles are not barely supported. They are included in the distribution precisely so that people can build pure-windows programs under Cygwin. Oh? Then I got the wrong impression from the documentation and the mailing list when I was trying to work all that out a few years ago. I can't find it now, but I could swear there was something about it being deprecated or partially supported or something. I think there is a tiny misunderstanding here. I believe that Jesse was talking about the -mno-cygwin option when he spoke of using a barely-supported option. Chris seems to have misinterpreted that to mean that MinGW cross-compilers themselves were claimed to be barely-supported. The -mno-cygwin option for GCC v3 was certainly deprecated for some time now and announced in the mailing list as I recall, and support for it always seemed uncertain at best to me. As of GCC v4, that option is dead; however, the MinGW cross compilers included with Cygwin continue to have full support. I hope I didn't just add to the confusion here. :-) -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: What Package Contains the cw (Color Wrapper) Software
On 01/27/2012 03:43 PM, lookingupw...@lavabit.com wrote: Oops. I'm signed up as digest and I forgot to include the subject RE: on the prev post. Thank you Larry! My problem is I am trying to download it via ftp rather than Cygwin's Setup.exe and I cannot find it on the ftp site. (I am limited by a proxy server from using Cygwin's setup.ext to find it directly). My understanding is that if you can get to one of the Cygwin mirrors with your web browser, you can get there with Cygwin's setup program. What error did you get when you tried to use the proxy support in the setup program? -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Distributed Git not compiled under Cygwin?
On 12/29/2011 04:31 PM, cxira wrote: Jeremy Bopp-3 wrote: Good stuff. You can avoid the window that pops up by using the run.exe program to kick off your chmod command rather than bash. It's available in the run package. I think the window is actually cmd.exe since this is a Windows gVim. That said, I switched the bash to run and tried the command prompt start (like in Unix) and it actually doesn't even appear at all now. Beautiful! silent execute !start C:\\cygwin\\bin\\run.exe /usr/bin/chmod 0644 ' . substitute(expand(afile), ^\\(.\\):/, /cygdrive/\\1/, ) . ' That's not bad, but I don't think you should need start at all. Yes, it will run something in the background, but the chmod command should return almost instantly, and it would be good to know if it errors out for some reason. You would lose any way to detect that if you spin it off to the background. The run program should do all you need to ensure that a Windows console doesn't pop up. I don't have Windows and gVim available at the moment though, so I can't confirm that. You should also use the cygpath program to convert your paths if possible. Your solution for conversion will fail if you ever work on a machine with a nonstandard cygdrive prefix. You probably won't run into it on your machines, but you may one day share your configuration with someone who will. :-) -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Distributed Git not compiled under Cygwin?
On 12/29/2011 04:38 AM, cxira wrote: Jeremy Bopp-3 wrote: I don't see any way around this except to either build your own Git that doesn't include the Cygwin changes or run a git config command to set core.filemode after cloning or initializing a repository. Sorry if I got your hopes up. Hopefully, the Cygwin changes aren't really a problem for you. Thanks a ton, actually. I appreciate the amount of time you spent looking into this. The link you provided answers my question exactly as to why they did it this way, as files created within the Cygwin environment adhere to the expected permissions. I realize now that my problem is more the exception than the rule, as I use the Windows gVim due to the better integration, which creates files with incorrect permissions. It seems that the best solution would be stick to compiling it myself or perhaps investigate to see if I can tweak gVim so that it will save files with the correct permissions. I never had a problem with the native gVim cooperating with Cygwin's Git (more accurately file permissions) either. Can you provide more detail about your situation? How exactly are the permissions broken, and for which application(s) are they broken? -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Distributed Git not compiled under Cygwin?
On 12/29/2011 02:28 PM, cxira wrote: Jeremy Bopp-3 wrote: I never had a problem with the native gVim cooperating with Cygwin's Git (more accurately file permissions) either. Can you provide more detail about your situation? How exactly are the permissions broken, and for which application(s) are they broken? Here's what I see: $ gvim temp :wq $ ls -al temp -rwx--+ 1 Doug None 0 Dec 29 15:21 temp Expected: $ touch temp2 $ ls -al temp2 -rw-r--r--+ 1 Doug None 0 Dec 29 15:22 temp2 It isn't a problem that causes a conflict with anything, but if I commit these files to the repository with their file modes as 0700, other people that use the repository may have problems with them (not to mention the show in as green executables in ls). I actually pushed these files to an Apache webserver for production one time and the entire site was not working for a bit because of that. The execute bit is the only permission that Git actually records: http://book.git-scm.com/1_the_git_object_model.html Unfortunately, it's the only one that's giving you grief here. You might try setting the noacl mount option for the Cygwin mount containing your repository: http://cygwin.com/cygwin-ug-net/using.html#mount-table Another option may be to hack a post-save action into gVim that uses Cygwin's chmod command to remove the execute bit from newly saved files: http://stackoverflow.com/questions/4627701/vim-how-to-execute-automatically-execute-a-shell-command-after-saving-a-file If all else fails, you could also install the Windows-native build of Git and use that instead. Cygwin's gVim may also make sense to use here instead of the native one, but I remember you saying that the native gVim integrates better for what you do. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Distributed Git not compiled under Cygwin?
On 12/29/2011 03:44 PM, cxira wrote:
I moved away from msysgit because it wasn't displaying colors properly in
mintty. As for a vim script, I put together something that executes `chmod
0644` when saving new files only:
Change permissions on new files to be 0644 in cygwin
augroup filePerms
autocmd!
autocmd BufWritePre * call NewFileTest()
augroup END
function! NewFileTest()
if !filereadable(expand('afile'))
If the file cannot be found pre-write, add a post-write command
autocmd filePerms BufWritePost * call NewFileAlter()
endif
endfunction
function! NewFileAlter()
Remove command after it is executed once
autocmd! filePerms BufWritePost
Change permissions
silent execute !C:\\cygwin\\bin\\bash.exe -c \/usr/bin/chmod 0644 ' .
substitute(expand(afile), ^\\(.\\):/, /cygdrive/\\1/, ) . '\
endfunction
There's a very brief appearance of the command prompt when I save a new
file, but I think it's a suitable and portable solution. Thanks for the
help.
Good stuff. You can avoid the window that pops up by using the run.exe
program to kick off your chmod command rather than bash. It's available
in the run package.
-Jeremy
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Distributed Git not compiled under Cygwin?
On 12/28/2011 03:14 PM, cxira wrote: I noticed when using the Git that is distributed under the Cygwin setup (Git v1.7.5.1-1) that, when creating a new repository, the core.filemode local setting is set to true. Being under Windows, this should be false because of how file permissions are handled. While lacking detail, the announcement about that version of Git mentions that there are some changes included to work around choices made upstream regarding file permissions management under Cygwin: http://cygwin.com/ml/cygwin/2011-05/msg00205.html This is nothing new for Cygwin's Git. There's a good chance that if you build from the Git sources distributed via setup.exe rather than the upstream sources, you will get a Git that behaves the same as the one shipped by setup.exe. All that said, I've never run into file permission issues using Cygwin's Git. You probably won't either as long as you don't need to host your repositories on FAT or FAT32 filesystems. If you would still prefer to have that setting set as per upstream while avoiding local builds, I believe you can set it as you need in /etc/gitconfig, and all repositories should inherit that setting unless the user explicitly overrides it in global or local config settings. I also remember reading somewhere once that you should be able create a configuration template that would be used by new repositories created by git init or git clone that can set the property as you need. I can't find any links for that at the moment though. :-/ -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Distributed Git not compiled under Cygwin?
On 12/28/2011 03:53 PM, Jeremy Bopp wrote: I also remember reading somewhere once that you should be able create a configuration template that would be used by new repositories created by git init or git clone that can set the property as you need. I can't find any links for that at the moment though. :-/ The manpages for git init and git clone have the information about the template directory. See the --template option for both commands. Sadly, neither this option nor the system-wide /etc/gitconfig file will work in this case because apparently core.filemode is always set in the local config for the repository being created as determined by the build time settings. This overrides the setting from the template as well as the system-wide setting in /etc/gitconfig. I don't see any way around this except to either build your own Git that doesn't include the Cygwin changes or run a git config command to set core.filemode after cloning or initializing a repository. Sorry if I got your hopes up. Hopefully, the Cygwin changes aren't really a problem for you. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Installing sshd on Windows 2008 R2 in a domain
On 12/22/2011 10:06 AM, RITTER, Philippe wrote: Hello, New fresh server. I'm trying to install sshd with all the latest release of cygwin. But when I what to connect as a domain user, I get only this error in the event log : Sshd: PID 3212: fatal: seteuid 10500: Permission denied I have googled all this afternoon, but all tips didn't help me. I tried running the service with a local account, a domain account, giving all the permissions needed with editrights, but still getting the error. Any clue from the list ? Check the User's Guide: http://www.cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview There is no clear cut single solution for you, but you do have a couple options available depending on your needs. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: setup 2.761 regression: '--quiet-mode' conflicts with '--packages'
On 12/22/2011 01:58 PM, Greg Chicares wrote: On 2011-12-22 18:08Z, Jon TURNEY wrote: On 12/21/2011 12:15 PM, Greg Chicares wrote: It appears that some recent change to setup.exe has unintentionally made '--quiet-mode' incompatible with '--packages' for command-line installs. [...] I've uploaded a snapshot of setup including this fix at [1], perhaps you could try it out and see if that resolves your problem [1] http://cygwin.com/setup/snapshots/setup-2.762.exe That snapshot fixes the problem and works just great for me. Thanks. My test installation just completed, and everything looks good for me too. :-) -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: setup 2.761 regression: '--quiet-mode' conflicts with '--packages'
On 12/21/2011 12:15 PM, Greg Chicares wrote: It appears that some recent change to setup.exe has unintentionally made '--quiet-mode' incompatible with '--packages' for command-line installs. A similar problem was reported here: http://sourceware.org/ml/cygwin/2011-12/msg00244.html Using current setup.exe version 2.761, this no longer works (although it still works with setup.exe version 2.738 from a few months ago): setup-2.761.exe --quiet-mode --site ftp://mirror.mcs.anl.gov/pub/cygwin/ --root C:/cygwin-1_7 --packages cvs That command takes only about one second, and the local subdirectory for downloads contains only setup.ini . According to setup.log.full (which is only about 4K), setup.bz2 is downloaded; then it says: I can confirm this report. I ran into this bug just yesterday but hadn't had a chance to dig into it. The system is a base installation of Windows 7 running under KVM, in case it matters. Let me know if there are any other details I can provide. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: saving list of packages
On 12/19/2011 10:33 AM, e...@iol.it wrote: From: marco.atz...@gmail.com 2) see ./setup --help at setup -P seems that -P accept one package a time. Example: setup -M -P arj ash atk ... Use commas to separate package names: setup -M -P arg,ash,atk,... -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cron still not working - even after rerunning cron config
On 12/16/2011 02:31 PM, Mike Brown wrote: I desperately need to get this fixed as I will be leaving for a trip on the 20th and have some cron stuff to run while I am gone. I ran cron-diagnose.sh, which now runs the cron-config, and changed from just-me to local system and that still didn't fix the problem. A ps -eaf shows that cron is now UID SYSTEM and not 0. But that did not make a difference. I set up the following entry in my crontab: 12 14 * * * touch /tmp/crontest The time came and went and no zero length file showed up. Running cronevents, the list had the following error line: 2011/12/16 14:12:01 [SYSTEM] /usr/sbin/cron: PID 2524: (Vidiot) WRONG FILE OWNER (tabs/Vidiot) Which file is it exactly complaining about? My crontab file, which worked under 1.5? What is needed to fix it? Where is the crontab file placed? Please, time is critical. Sorry that I can't help you with your cron problem, but have you considered using the Windows Task Scheduler instead given the urgency of your situation? It can be used to kick off Cygwin processes just like any other. You'll need to wrap your existing tasks with a script in order to ensure that they receive the right environment, but that may be easier than debugging cron at this time. -Jeremy signature.asc Description: OpenPGP digital signature
Re: I gave up and reverted to 1.5
On 12/16/2011 10:55 PM, Mike Brown wrote: Long standing programs like cron just install and run. Using cygwin 1.5, it does. Using 1.7, it does not. I have no idea what was done to 1.7 to cause cron to not work, no matter what the Hell I try to do. So I said f**k it and removed all of the 1.7 files and reinstalled 1.5 from the local files that I have. Did you ever try to install 1.7 from scratch rather than attempt an upgrade of 1.5? The upgrade /should/ work, but it's also pretty easy to try a fresh installation. You can even do it along side your 1.5 installation so that you can work out the kinks without making your system non-functional. Regarding your cron and sshd issues, the only other thing I can think that would bust them both as you described is the change to user access token management. The details of how things are in 1.7 are here: http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview Basically, things have changed, but I can't really tell you what exactly myself. I can assure you though that while I never had need of cron I did make extensive use of sshd under Cygwin 1.7 on Windows 2000, XP, 2003, 2008, and 7 systems. It worked well for virgin systems, but I may have had to clobber the accounts used for sshd services and re-run ssh-host-config on systems where I upgraded from Cygwin 1.5. That was some time ago now, so I can't remember for sure. If in doubt, start everything on a virgin system to prove that you can get things working. Then compare with the upgraded system to figure out the differences. Of course, if there's no compelling need to upgrade to Cygwin 1.7, skip it and have some fun in your life. ;-) -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Sorry people (NOT MY taxonomy!!), but igncr IS flawed
On 12/16/2011 11:13 PM, manu0507 wrote: Hi all, Notwithstanding the completely preposterous reply by Eric Blake (more of an idiotic acrimony, actually) to my previous post (see http://old.nabble.com/Igncr-ineffective--tt32983438.html ), there does seem to be a problem in dealing with Win's CR/LF line endings in unusual lines, at least on Win7-64 (or, to be really precise, on my Win7-64). The lines where CR/LFs appear not to be properly converted to LFs seem to be empty lines (except for the CR/LF, of course), as well as some other unusual constructs (lines ending with ;;CR/LF in particular). I don't have Cygwin available at the moment, so I can't try running scripts as you describe right now. However, the claim that a line consisting of only a CR/LF causing problems with the igncr option makes me pretty suspicious. Empty lines are pretty darn common in bash scripts, and I would expect to have seen many reports of problems with igncr reported here by now if that option didn't correctly handle those lines. Can you send a representative example script that elicits this problem for you? A simple test case would go a long way to addressing the issue. From the sound of things, no one else has reproduced your issue yet. Perhaps the lines that are giving you trouble are actually ended with CR/CR/LF. Have you examined the problematic scripts with a hex editor or simply od -c to verify the line endings? To work around the problem, I'm writing an application that would convert all CR/LF-ending text files into LF-ending ones... but it's not really trivial, because telling binary files that should be left untouched from text files that should be converted is difficult: even the very first file in GDB's sources (configure) contains a '\a', i.e. a not-text byte. While it's not a complete solution by itself, I hope you're using the dos2unix or d2u programs to handle the conversion. You may also be able to make use of the file program from the file package to help identify files that are appropriate for conversion. Given that the igncr option is only useful for bash and maybe sh, scripts for those are probably the only ones you want to convert, and the file program should be able to identify them for you. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Symlinks and sharing a home directory between Windows and Linux
On 12/14/2011 01:33 PM, Andrew DeFaria wrote: I like having only one home directory. It's extremely convenient to have the same settings and the like both when on Cygwin and when on Linux. Often home directories are on NAS's and the like and served out via smb. Somewhere along the line Cygwin's symlink implementation changed again. It used to be that symlinks ended in .lnk, which was sort of a pain but workable. One nice thing is that they didn't clash with Linux symlinks. A Cygwin symlink is not the same as a Linux symlink and so you could have: $ ln -s a_file.txt link1 # in Cygwin $ ln -s a_file.txt link1 # in Linux and you'd end up having a symlink with the same name, link1, pointing to the same file from either Cygwin or Linux. This is because the Linux symlink is named just link1 and the Cygwin symlink is named link1.txt. But now Cygwin names its symlink link1. When you then log into Linux and try to access that link it doesn't work. Where this is happening for me is that I put all of my rc files under ~/.rc and then I symlink them to ~ as appropriate. So, for example I have a ~/.rc/inputrc. I then symlink them to ~/.inputrc. Under the old scenario I'd get a ~/.inputrc.lnk for Cygwin and a ~/.inputrc on Linux. Under the new scenario I get a clash. Is there any way around this? Would a hard link work instead? -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Latest cygwin.bat - need one
On 12/12/2011 11:44 AM, Mike Brown wrote: snipped doc references... In other words, no where in the documentation is it stated that mintty is now the default startup. It all leans toward cygwin.bat as being the way things are started. So, just what is a user supposed to think when reading the documentation. When I did the install, I told it not to install the desktop shortcut, as I already have one. There was no indication during the install to inform the user that mintty is now the default startup, instead of cygwin.bat. Those are good points about the documentation. The change to mintty happened fairly recently though, so I'm sure the documentation will be updated sometime soon to reflect the current reality. You may be able to contribute patches for the documentation if that interests you enough. At this point in time, I have no clue as to how to set up cygwin to use it, just to see what it is like. I would try installing fresh to a new directory and taking all the defaults, from package selection to shortcut creation. Leave your current installation alone since it probably has some settings you don't want to lose or that may interfere with a fresh Cygwin experience. Once you figure out what your original installation needs, you can copy those changes over either manually or by re-running setup.exe as necessary. The rxvt program has been working for me. I used to use rxvt a long time ago, but it's dead upstream from what I last heard. Don't expect much help if it doesn't work in Cygwin. Urxvt is probably your only option if you *must* use something like rxvt for some reason. It requires X to be running though... Mintty is a big improvement over the Windows terminal and rxvt, so give it a try. If you don't let setup.exe create the shortcut for you, it's as easy as creating a shortcut that runs mintty as follows from within the bin directory of your Cygwin installation: mintty - That will start a login shell for you using the shell you have configured in /etc/passwd. From there you can configure mintty by right clicking to open a context menu and opening the the configuration dialog. You can find more documentation by reading mintty's manpage. Good luck. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Latest cygwin.bat - need one
On 12/12/2011 03:23 PM, Mike Brown wrote: In my case that is a no go. That is because, as mentioned, I told the installer not to create the desktop shortcut or the start menu option, as I already had them. So, the start menu currently points to the BAT file. Hmm, it seems that my messages aren't getting through since I mentioned how to create such a shortcut just a little while ago, but I'll try one more time... Create a shortcut that starts in the bin directory of your Cygwin installation. Have it run: mintty - That's it as far as I remember. Of course, the easy way is to just run setup.exe again and let it create the shortcut for you. Then you know you have the right settings. If there is an example of what the desktop shortcut has for the properties, I can create one to see what mintty looks like. I've never used mintty under Solaris or Linux. Mintty doesn't exist under Solaris or Linux, only Cygwin. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Latest cygwin.bat - need one
On 12/12/2011 07:37 PM, Mike Brown wrote: On Mon, Dec 12, 2011 at 04:11:48PM -0800, Gary Johnson wrote: General [Name:] Cygwin Terminal Shortcut Target: C:\cygwin\bin\mintty.exe -i /Cygwin-Terminal.ico - Start in: [empty] Shortcut key: None Run: Normal window [Icon:] C:\cygwin\Cygwin-Termina.ico Thanks, I created a shortcut with the above info and it is close. It starts and it finds my shell and my config files. But $SHELL is empty and the terminal has no clue as to where any of the Cygwin programs are. The PATH that is created before any of my files are read contains info on Windblows program locations, but nowhere is /usr/bin or /bin, or any of the long path names to the Cygwin binaries. When started from the cygwin.bat file, /usr/local/bin:/usr/bin:/bin: prefice the Windblows paths. So, a PATH that includes the needed info to the cygwin binaries is built when BAT is run, but not when mintty is started. Is there a reason why Cygwin is not building a PATH with the needed info? As I recall, all of the PATH settings are handled in /etc/profile and files in /etc/profile.d. It sounds like you have a problem somewhere in there. Maybe you made local changes that prevented the package that provides /etc/profile from updating it when you upgraded Cygwin. Try installing a fresh instance of Cygwin to a different directory and see if things behave better there. You can leave your current installation where it is without much risk of interference, assuming your shell startup scripts don't have any hard coded paths to the original location. I've modified my environment resource file to look for $TERM == xterm and added the needed Cygwin paths. That shouldn't be necessary once you get the real problem sorted out. BTW, what is with white text on a black background? UGGHH! :-) To each his own. Hopefully, you found all the configuration options so that you can change it as you please. :-) -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin limping after update (subject chage)
On 12/09/2011 01:03 PM, Mike Brown wrote: On Fri, Dec 09, 2011 at 12:28:36PM -0600, Mike Brown wrote: Now I need to know why the rxvt program is not working correctly. Still do not know why that doesn't work. You may or may not like this answer, but try using mintty instead. It's the default terminal program for Cygwin now and works extremely well. Rxvt has long been abandoned (even upstream), and while I haven't heard that it's known to be broken, it's probably not likely to get a fix even if it is. If you're hooked on the rxvt interface/behaviors, I've heard that urxvt still works somewhat recently, but you'll need to run an X server in order to use it, unlike mintty and rxvt. As for ssh, I've run the ssh-user-config and ssh-host-config and started the daemon. When I try and log in from my Solaris box, it keeps asking me for the password, i.e., it can't correctly determine what it is. I use: ssh -l vidiot PVRpeecee The other ssh daemon was able to get my password correct. Any idea why openssh can't figure out my password? Have you confirmed that your /etc/passwd file is correctly configured for your user? The username you use with ssh will need to match an entry in there, and that entry will need to have the correct SID for a real Windows account associated with it. You may need to try at least partially regenerating the passwd and group files using mkpasswd and mkgroup. It might also be good to check the Windows event log as well as /var/log/sshd.log. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Minor cygrunsrv nit: --help should go to stdout, not stderr
On 11/28/2011 10:05 PM, Daniel Colascione wrote: Currently, cygrunsrv --help dumps output to standard error. This behavior is a slight annoyance because it results in cygrunsrv --help | less not being very helpful. Can cygrunsrv --help dump its output to stdout instead? It's not the first program I've seen behave that way, but it doesn't seem to be common behavior when explicitly requesting help output like that. In case you don't know, you can work around it by redirecting stderr to stdout: cygrunsrv --help 21 | less -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: setup.exe (Release 2.761)
On 11/21/2011 09:06, Corinna Vinschen wrote: A new version of setup.exe, release 2.761, has been uploaded to http://cygwin.com/setup.exe. Changes: - Now that mintty has become part of the default installation, setup will create desktop and start menu shortcuts called Cygwin Terminal, which point to mintty, starting your default shell as noted in /etc/passwd. That right there is awesome. Congrats to Andy for making the best damn Cygwin terminal ever! Thanks to everyone involved with finally making it the default Cygwin terminal. :-) -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Rolling back to 1.6.x Subversion
On 11/17/2011 01:39, Andrey Repin wrote: Greetings, Jeremy Bopp! All I really wanted to know was why it was important to hang back from the latest available version when getting the older one was less than trivial. Not using anything more than the command line for svn (infrequently at that) made me forget how often that project changes formats in the working copies and the ramifications of that behavior. On my memory, it wasn't changed even once in four years. Or all changes were transparent. The main problem with 1.7 I see myself, I described earlier: No way to tell at a glance, if the directory you're working with is versioned or not. I want to think that they only change the working copy format when the minor version changes, but I also think that they have done that with every minor version transition since at least 1.4. I know I remember seeing the client request to upgrade my working copies at least once before anyway. Whether or not that upgrade was required, I can't say. Regardless of the time period between minor version bumps, that rate of change in working copies seems excessive to me given the relative stability of other SCM tools, but that's just my likely ignorant opinion. ;-) Maybe like you say, the other transitions allowed for some backward compatible support. It's odd then that they wouldn't allow for that in the 1.7 client. I would expect the 1.7 client to at least support *using* existing version 1.6 working copies in order to avoid exactly this sort of interoperability issue, but it sounds like it does not. That's very unfortunate if true. If true, maybe it would make sense to allow for parallel installation of svn versions that differ by minor number and use the alternatives system to allow the user to select a particular one if they decided to install both. In other words, it would be handy to offer something like subversion16 and subversion17 packages as well as an alias package named just subversion that would pull in the latest version. That's probably more work than it's worth though given the number of sub-packages also offered with subversion. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Rolling back to 1.6.x Subversion
On 11/17/2011 05:12, Csaba Raduly wrote: On 11/17/11, Andy Koppe wrote: Can one use different svn clients on the same working copy, even if they are the same version? I've always been wary of that due to fear of subtle differences in working copy format. Character encoding and line endings are two possible trouble spots that come to mind. I regularly use Cygwin's SVN and Subclipse in a Windows version of Eclipse and never had any problems. I had to postpone upgrading to the Subversion 1.7 Cygwin package until Subclipse 1.8 came out, which supports the 1.7 working copy format. One of the really smart things that the SVN project has done is insulate the working copy from most of the horrors of line ending differences. The administrative files appear to either have a strict line ending definition for all platforms or (more likely) clients are expected to be flexible regarding line ending handling within the files. The use of the svn:eol-style property on source files allows for a great deal of flexibility regarding management of line endings within the working copy. Ultimately, any problems boil down to the text editors in use and not the various SVN clients. As far as I can see, only the combination of setting svn:eol-style to native and using a crummy text editor could expose unexpected problems when mixing Cygwin and Windows SVN clients within a single working copy. Those problems would really only be in the text editor and not SVN however since the text editor could receive a file with unsupported line endings if the Cygwin client checked the file out. Either SVN client would do the right thing with the file upon commit regardless of the line endings it ended up having after editing. There can't be very many users out there mixing both Cygwin and Windows SVN clients with a text editor that completely chokes on Unix line endings. :-) I've been really impressed with how gracefully SVN handles this whole line ending issue. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Rolling back to 1.6.x Subversion
On 11/17/2011 10:09, Jon Clugston wrote: On Thu, Nov 17, 2011 at 10:37 AM, Jeremy Bopp jer...@bopp.net wrote: I want to think that they only change the working copy format when the minor version changes, but I also think that they have done that with every minor version transition since at least 1.4. I know I remember seeing the client request to upgrade my working copies at least once before anyway. Whether or not that upgrade was required, I can't say. This is all explained quite clearly in the documentation on the Subversion web site. Each minor release is allowed to change the working copy format in a non-compatible way (the lower numbered clients can't safely use it). This simplifies the development of Subversion but causes a (to me at least) very minor annoyance that all clients that will use the same working copy must be at the same minor release. This, however, doesn't stop anyone else who writes Subversion clients from transparently supporting multiple client versions simultaneously (and dealing with the complexity that creates). Thank you for confirming my memory regarding these format changes. Still, while it makes sense for the project to make backward incompatible changes at times, it still seems odd that the new clients wouldn't support using the working copies from at least 1 minor version back in order to ease interoperability between SVN client implementations. I could see that the new clients wouldn't *create* older version working copies in order to encourage adoption of the changes, but it wouldn't seem too hard on the face of it to keep around a compatibility layer from the last minor version in order to *use* an older working copy. It's the maintainers' decision how they build their project, of course. I just find this aspect surprising. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Rolling back to 1.6.x Subversion
On 11/15/2011 15:47, Sean LeBlanc wrote: I've accidentally updated Subversion to 1.7.x on Cygwin. Is there a way to get an older package of Subversion installed? It looks like you'll need to check out the Cygwin Time Machine (http://www.fruitbat.org/Cygwin/index.html#cygwintimemachine) if you want to go back to version 1.6. That whole process is going to be unsupported here though, so is there some reason you must remain on such an old release of subversion? -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Rolling back to 1.6.x Subversion
Jim Garrison jim.garri...@troux.com wrote: -Original Message- On Behalf Of Jeremy Bopp Sent: Wednesday, November 16, 2011 9:18 AM Subject: Re: Rolling back to 1.6.x Subversion That whole process is going to be unsupported here though, so is there some reason you must remain on such an old release of subversion? Um... 1.7 just came out in the last few months, 1.6.17 isn't such an old release. Consider users who depend on clients (SVNKit) that don't yet have 1.7 native support (i.e. Subclipse). We have to stay on 1.6 until ALL our clients support 1.7 due to the working copy restructuring. When 1.7 came out I saved a copy of the 1.6.17 distribution locally. Seems that I stepped on some nerves due to my poor choice of wording. Sorry about that. All I really wanted to know was why it was important to hang back from the latest available version when getting the older one was less than trivial. Not using anything more than the command line for svn (infrequently at that) made me forget how often that project changes formats in the working copies and the ramifications of that behavior. Thanks for enlightening me. :-) -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Issue downloading appropriate DLLs for CDRTools
On 11/9/2011 15:43, Dr. Torsten Kühn wrote: A couple of days ago, I had serious problems finding the appropriate DLLs for a recent Win32-port of Jörg Schillings famous CDRTools. The port done by Thomas Plank available at http://www.student.tugraz.at/thomas.plank/cdrtools-3.01a06-win32-bin.zip is based on Cygwin. Cygwin includes the wodim package which comes from cdrkit which itself is a fork of cdrtools. Install wodim and give it a try. It has always worked great for me. I intended to use CDRTools/ CDRecord as my only Cygwin-application (perhaps more one day), thus no current need install the entire Cygwin distribution. A minimal Cygwin installation isn't that large, so it would be better to go ahead and install one and add in the package you need. You can assemble things by hand if you like, but you'll be spending your own time to deal with it as you discovered. Alas, Thomas' package lacks a comprehensive set of DLLs required to run CDRecord standalone (the port has obviously been developed within a Cygwin environment, so the author could not track which DLLs exactly are required to run his binaries). Thomas is likely aware of the licensing issues surrounding including the Cygwin DLL and other supporting DLLs in his archive. While the terms aren't necessarily onerous, they may be more of a headache to comply with than Thomas wants to bother. Apparently, the current download system relies on http://cygwin.com/setup.exe (562 KB, as of 2011/11/04). Alas, this tool cannot be used with my systems, as the dial-in host only runs LX-executables, and the Win32- computer intended to run CDRTools cannot access the internet via Squid neither, due to an unsupported onboard ethernet chip. Setup.exe supports installing from a pre-downloaded set of package files. You can perform an Internet-based installation on a machine with a functional Internet connection to get all the packages you'll want to install and then copy the directory setup.exe creates to hold the downloaded package files onto a DVD along with setup.exe itself. You should then be able to run setup.exe from that DVD and tell it to use the package files already on the DVD for installation. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Pass windows-style paths to the interpreter from the shebang line ?
On 11/9/2011 09:29, Corinna Vinschen wrote: That's not as easy as it may sound. What about creating wrapper scripts with the same name in another dir and put that dir in front of the other bin dir in $PATH? The wrapper scripts could be shell scripts which use `cygpath -wa' to convert the path to DOS notation and then call php. I'm surprised that we don't have php in the Cygwin distro. Did nobody try to port php to Cygwin yet? It looks like php is available in Cygwin Ports. I've not tried it to see how well it behaves though. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Pass windows-style paths to the interpreter from the shebang line ?
Sorry to reply again, but I hit send too early... On 11/9/2011 09:29, Corinna Vinschen wrote: That's not as easy as it may sound. What about creating wrapper scripts with the same name in another dir and put that dir in front of the other bin dir in $PATH? The wrapper scripts could be shell scripts which use `cygpath -wa' to convert the path to DOS notation and then call php. Does php not have an equivalent of the -S option (search the PATH for the named script) that perl and ruby have? I've used that many times to deal with cases where people have Windows-native builds of those tools instead of the Cygwin ones for whatever reason. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Copy, paste and deleting characters in the openssh screen.
On 11/9/2011 08:38, gabier wrote: Hi, I am experiencing daily frustration because I do not know how to get the following features to my fingertips while controlling my Freenas/FreeBSD server from my openssh console on a remote Windows computer. 1) copy from windows document or browser and paste in the openssh console 2) copy from the openssh console and paste either on another line of the console or on a windows document While you can get this to work with the default Cygwin terminal (cmd.exe), you would be better off installing the mintty package and using that for your terminal instead. You can configure it to behave like a typical xterm with respect to copying and pasting, so you may find that much more familiar. To copy and paste from a regular Windows program, highlight the text and press CRTL-C to copy as usual. Then go to your mintty window and paste using the method you configured for it in its configuration dialog. I think pressing SHIFT-INS should work by default, but there are other options available, including middle clicking (not the default IIRC). To copy and paste from the mintty window, highlight the text and then copy using the method you configured for mintty. I have my mintty configured to copy automatically when text is highlighted, but that's not the default as I recall. Once the text is copied, paste into a Windows program as usual with CRTL-V or paste back into the mintty window as discussed previously. 3) correct my openssh commands by deleting characters with the backwards stroke. Sometimes it works, sometimes not, it seems to depend on the type of login! The local user (Cygwin) seems to work, the root user on the freebsd server seems also to work, but another user on the freebsd server does not work : if I hit the backward stroke it prints a triangle (meaning I suppose unknown character) and there is no way to correct this but to send the wrong command and retype the whole command. With long commands it can be very frustrating. This may get corrected automatically by using mintty as your terminal, but it's really not a Cygwin-specific issue. I've had similar problems in the past and was able to work around them by pressing either CTRL-H or CTRL-BACKSPACE. My vague understanding of the problem is that the terminal sends a particular character in response to the backspace key, which is configurable in many terminals. Mintty is one such terminal, but the cmd terminal is not. Without the ability to change the character sent by the terminal program, you would need to be able to configure the remote applications to do the right thing with whatever character *is* sent, but that can be a tall order due to the different ways you may have to configure each application. As I said, that is only my vague understanding of the problem, so it could be subtly or glaringly inaccurate. In any case, however, you will likely avoid the problem by using mintty. :-) -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Can't get sshd to work
On 11/4/2011 08:58, gabier wrote: Ken Brown-6 wrote: On 11/4/2011 8:17 AM, gabier wrote: Hi everybody, First post here, I am a Cygwin newbie. I try to implement ssh connectivity between my Windows 7 desktop and a FreeBSD/FreeNAS server. Openssh shell commands seem to work, but sshd is not running and thus network commands issued from the server abort because of connection refused. The sshd windows service is automatically started at windows startup, but it is not running. If I start the service by Windows command, it starts and stops immediately (Windows saying). If I start it at the command line with ssh I tried 2 ways $ /usr/sbin/sshd.exe /etc/sshd_config: No such file or directory $cygrunsrv --start sshd cygrunsrv: Error starting a service: OpenService: Win32 error 5: Accès refusé. I searched this forum but I am lost in the variety of parameters and reasons of not working, as well as different versions. In fact I downloaded the cygwin setup, and installed the default packages, and afterwards I installed the openssh package (5.9). What is to be done in order to debug this problem ? Is sshd simply lacking a sshd_config file ? Then how to build it ? Did you run /usr/bin/ssh-host-config ? No, I had not. I did not know I had to. Well, I ran it, but it asks me if I want privileged separation or not. I searched a little on internet to know what this is. It seems a good architecture, but I am feared that being rather new it introduces new problems. Does it work well now and is there a manual or how to in this context ? If I choose NO, is it dangerous but more simple ? Privilege separation has been around for years now, so there's no risk with using it, really. Unless you know better, you should take all the defaults provided by ssh-host-config. You can always run it again later to change something. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How to run a bash script that calls a Win exe under Windows without installing Cygwin?
On 10/19/2011 02:57, bagvian wrote: Dear all, I have gone through Cygwin FAQ and documentation, did some googling but could not find any answer to my cross system problem. I currently work under Win Vista and have a proper Cygwin installation running perfectly. I have to perform heavy tests on a Windows console executable program say: MYPROG.exe (obtained by using MS Visual Studio). To test such a program I have written a bash shell script, say: MYSHELL.sh, that does the following things: 1/ Build up data files 2/ Launch my Win exe: MYPROG.exe 3/ Organise all the resulting data This procedure works perfectly on my own machine and all my tests are performed by only running MYSHELL.sh in my Cygwin console. Now, I need to perform the same test procedure on another Win Vista machine where Cygwin is not installed. I therefore have to find a solution around the Win prompt (cmd.exe). Basically, I can copy anything on that machine but I cannot install Cygwin. Is there a way to run my script MYSHELL.sh within Win prompt by only copying Cygwin dll (cygwin1.dll) at the right place and maybe changing some settings ? Would it be possible (better) to adopt another strategy that would be to write a macro Win console exe file that can run in the Win prompt and that would kind of embed / link with: cygwin1.dll, MYSHELL.sh, MYPROG.exe ? I thank you in advance for any suggestion. Copying around a partial Cygwin installation is definitely not supported on this list. It can certainly be done, but you'll be on your own when it breaks down. Depending on the needs of your script, you may also find the task of gathering everything together to be cumbersome. If you truly can't install anything onto the test system by way of a proper installation program, you're probably better off replacing MYSHELL.sh with something else that already is available natively on the system. There are a number of options potentially available to you including cmd, Windows Script Host, and PowerShell. FYI, the Cygwin installation isn't really much more than a reliable and supported way to get the things you need for Cygwin copied to the right location on your hard drive. The setup program only adds a few things to the registry aside from copying files into place, and you can probably delete those registry entries after setup completes without affecting Cygwin itself. Actually installing Cygwin shouldn't adversely affect anything else on the system that isn't already aware of Cygwin, so if you really do need Cygwin or parts of it, you should try to argue for Cygwin's inclusion on the test machine. It sounds like you might be better served by one of the alternatives I mentioned though. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How does setup.exe cope with upgrading of already installed packages if there exist modification in installed files?
On 10/19/2011 09:13, Andrew Schulman wrote: How about templates? For example if package like Mercurial provide WEB templates which I like to customize (fix time format to ISO-8601). Templates lies in /lib/python2.6/site-packages/mercurial/templates/*. It seems that that's something you'll have to work out with the Mercurial package maintainer. A postinstall script can certainly check to see if templates have changed, and if they have either leave them in place, or even merge in new changes, if you can work out a good way to do that without prompting the user. According to this page, you can change where hgweb looks for templates by editing either /etc/mercurial/hgrc or the .hgrc file in the home directory of the user running hgweb: http://mercurial.selenic.com/wiki/Theming Rather than making a complex postinstall script than can manage overrides sanely, it would be better to copy the packaged template files into a new location outside of the paths managed by the packages and then configure hgweb to look for them in the new location. You'll then be free to make any changes you like then without fear that they will be inadvertently clobbered. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fw: 1.7.9-1 path issues
On 10/14/2011 15:33, David Bartlett wrote: Recently I updated from a thinkpad T61 to a T410 and installed cygwin on it exactly as I had on the T61. The only difference was that on the T61 I had an older version of cygwin installed (I'm not sure which one but it would have been from around mid 2009). in my .profile i have my HOME variable set as HOME=/home/dcbartlett I have other variables set up in my profile that take the HOME value as a root. DC_ROOT=$HOME/bcystage/app/xform/DC_Scripts; export DC_ROOT DC_ERROR=$DC_ROOT/log; export DC_ERROR DC_REFRESH_MSG_FILE=$DC_ERROR/refresh_msgs.txt; export DC_REFRESH_MSG_FILE; I have unix scripts that use those variables and they call sqlplus which in turn uses those variables in spool commands. The issue is that the logging the unix scripts perform works but the spooling from sqlplus does not. If I change the HOME variable to HOME=C:/cygwin/home/dcbartlett the unix logging no longer works but sqlplus spooling does. In both cases I get file not found messages. Setting HOME to C:/cygwin/home/dcbartlett worked for both unix and sqlplus on my old laptop (with the older version of cygwin). And I don't recall doing anything funky to get that to work. Does anyone have any idea on how I can resolve this without having to create one set of variables for Oracle and one for Unix. I am not sure if this is a cygwin issue or an oracle issue. This is neither an Oracle nor a Cygwin issue. Cygwin programs usually expect and sometimes require Cygwin paths while Windows-native programs, such as sqlplus, always require Windows paths. Since your previous Cygwin version (likely in the 1.5.x series), many changes have been made to how Cygwin handles paths. The Cygwin developers never promised that Windows would work with Cygwin tools. They never attempted to break things intentionally, but it seems you've been bit by using a bad assumption about path compatibility. Without seeing your scripts and how they use the variables for their logging tasks, no one can really say much about what specifically you can do. Generally though, don't mix Windows paths with your Cygwin tools and never mix Cygwin paths with your Windows tools. I can think of 2 options for your situation: 1) Use relative paths everywhere. 2) Write wrapper functions or scripts for all your Windows-native programs that get called with these paths. The first may not work for you if you need to hop around within various working directories while ensuring that the paths still refer to the same location. If you can ensure that your scripts always run all programs from within a single directory though, this is the easiest option since you probably won't have to perform any path conversions. If the first option is not possible, you can wrap all calls to the Windows-native programs in either functions or shell scripts. The wrappers would then be responsible for processing all paths given to them with cygpath in order to make them something usable by the Windows-native programs that they call directly. This will localize the places where you perform conversions without the need to carry two versions of every variable containing a path through your scripts. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: login: no shell: /bin/bash: Permission denied
On 9/13/2011 13:38, Larson, Donald (Don) wrote: I understand su does not work – answer use ssh. SSHD cannot start because user sshd cannot login. I run login sshd type in the password and then I get the message. What you're saying is that you want a way to log in as another user as one would with the su command, right? If so, you need to get the sshd service working first so that you can at least log in as yourself. The process for doing that is documented in /usr/share/doc/Cygwin/openssh.README. Read this carefully. If you have problems with this part, submit a problem report as Larry suggested. When things work, you should be able to run something like the following command to log in as yourself over SSH: $ ssh your_username@localhost Once you're able to log in as yourself, you can set up account details for other accounts in /etc/passwd in order to allow yourself to log in via SSH using those accounts. The mkpasswd program will help you here. This is the tricky part. For accounts that have no password such as the SYSTEM account or for accounts whose passwords you do not know, you need to set up public key authentication so that you can authenticate over SSH without a password. You may also need to make some manual edits to your /etc/passwd file in order to set home directories and shells for accounts such as SYSTEM where those settings are not defined by default. If you need details for how to use public key authentication with SSH, there are numerous articles available online. For your needs here, there is nothing Cygwin specific about setting this up. This is what I did just now to allow me to log in as the SYSTEM account: 1) Create the directory /root/.ssh. 2) Copy your SSH public key file to /root/.ssh/authorized_keys. 3) Set the owner of /root and its contents to SYSTEM. 4) Open the /etc/passwd file in a text editor. 5) Modify the line that starts with SYSTEM as follows: a) Insert /root before the last colon on the line. b) Append /bin/bash after the last colon on the line. 6) Save the changes. Now you should be able to log into the SYSTEM account by running: $ ssh SYSTEM@localhost -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: login: no shell: /bin/bash: Permission denied
On 9/14/2011 14:25, Ryan Johnson wrote: Question: in my experience sshd will not allow connections to users who have no password set, even when password-auth is not used. This happened on my wife's laptop, for example, where I ended up having to create a dummy user for myself that had a password, since she didn't want her account to have one. Does SYSTEM have some sort of password after all? No, I don't think it has a password, especially since its use is disallowed for user logins in the first place, but I can't find any reference to back up my assertion at the moment. I can't explain your experience with password-less user accounts though. I've never tried that configuration with sshd myself. Is it possible that you neglected to add your wife's account information into /etc/passwd before attempting to log in using it? You'll get rejected by sshd just like you describe unless the account you're trying to use is listed in there. Having the correct SID listed in the user information is critical. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Typical Cygwin fork problem
On 8/19/2011 11:38, big glass wrote: so what is ash exactly?? ash is another name for dash, which is described here: http://en.wikipedia.org/wiki/Debian_Almquist_shell The short answer is that it's a minimal shell that you need to use in your case for running the rebaseall command so that there aren't any DLLs locked by other Cygwin processes. BTW, make sure that you exit all Cygwin processes except for ash before you start rebaseall. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: how to access to drive using cd
On 7/15/2011 12:32, dbonneau wrote: Hi, I am trying to access to a drive call Q when I acess to c drive by typing cd /c , it works fine but not with cd /q could you tell me how to do that ? Assuming you're running under the Cygwin Bash shell, the default way would be the following: cd /cygdrive/q If that works for you, then someone has done something special to make /c point to the correct path while failing to do the same for all drive letters. If it doesn't work, then we'll need more information from you. Following the problem reporting guidelines would help us help you better: http://cygwin.com/problems.html -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: how to access to drive using cd
On 7/15/2011 13:02, dbonneau wrote: Jeremy Bopp-3 wrote: On 7/15/2011 12:32, dbonneau wrote: Hi, I am trying to access to a drive call Q when I acess to c drive by typing cd /c , it works fine but not with cd /q could you tell me how to do that ? Assuming you're running under the Cygwin Bash shell, the default way would be the following: cd /cygdrive/q If that works for you, then someone has done something special to make /c point to the correct path while failing to do the same for all drive letters. If it doesn't work, then we'll need more information from you. Following the problem reporting guidelines would help us help you better: http://cygwin.com/problems.html -Jeremy Hi, Thank you for you reply. I tried cd/cygwin/q but it said no such file or directory.. You have an error in the path you entered (at least in this message). It should be /cygdrive/q rather than /cygwin/q. Can you confirm that you actually tried the command exactly as I sent it originally? Copy and paste it into your terminal to be sure: cd /cygdrive/q -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Who's using CYGWIN=tty and why?
On 5/10/2011 09:50, Bernhard Ege wrote: I generelly use command line editing a lot (is tty necessary for that?). General command line usage doesn't require the setting. If in doubt though, remove the setting and try things out for a bit. You'll probably find that nothing changes for your usage, but it's possible you have a use case no one else considered yet. My other use is to open a Command window using windows explorer to have it change directory to the shown directory (shift-right click-Open Command Windows Here). From that windows I type C:\cygwin\bin\bash -l to get a cygwin prompt. There I type cd - to get back to the chosen directory to perform whatever task I need (mostly grep, find, running make, again some command line editing, rarely using an editor). You should check out the chere package. It will allow you to directly open a Cygwin shell from the context menu rather than jump through the hoops you're doing here. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: determining what user mounted a drive
On 5/10/2011 16:25, Len Giambrone wrote: Is there a way of determining with what user credentials a share was mounted? I suppose I could touch a file on the drive and then find out who the owner is, but that's not ideal. mount will tell me that it's a user mount, but won't tell me WHICH user. Is there some way (windows native or Cygwin) of getting this information? Are you asking about shares mapped to drive letters using a Windows-native process such as net use, or are you asking about shares mapped to Cygwin paths using the mount command? -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Who's using CYGWIN=tty and why?
On 5/9/2011 16:14, Karl M wrote: I did try rxvt and didn't like the way it looked, so I stayed with a console window and CYGWIN=tty. Hi, Karl. Have you tried mintty yet? If looks are what turned you away from rxvt, I think you'll like mintty much more. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Issue with SCP and SSH on Windows 7
On 5/6/2011 12:54, Metroshica wrote: I have recently written a script in Windows Server Edition 2008 that SSHes into a few linux servers, and then uses SCP to copy a file out of them. The issue I'm having is with SSH keys getting set up, and cygwin trying to create a .ssh directory in the C:/ directory, instead of where cygwin is located. Check to make sure that you don't have the HOME environment variable configured to C:. If it is, you need to remove it just in case, but you may try adding it back once you get things working. Next, you need to check that the user account used to run scp has an entry in the /etc/passwd file within the Cygwin installation: grep ^the_user: /etc/passwd That won't output anything if the_user does not have an entry in that file. Otherwise, you'll see the record for the_user. If you see such a record, take a look at the path that appears between the last and second to last colons in the line. That path is the home directory that Cygwin programs such as the SSH tools will use. Set it to a Cygwin-style path that points to the proper location. If the grep command doesn't output anything, you can add an appropriate entry by running the following from the bash shell: mkpasswd -u the_user -d /etc/passwd If the account is *not* a domain account, use this instead: mkpasswd -u the_user -l /etc/passwd These changes should correct the issue by allowing the SSH family of programs to correctly find the user's home directory as configured under Cygwin. I'm running this program through the standard windows command prompt, not cygwin's shell, as it is an automated process, and I don't know how to automatically run a program in cygwin. Anyone know how I can change the home directory to be C:/cygwin/home/user instead of the base C:/ dir, or anyone know how to automatically run a script in cygwin? Thanks for the help. You should be fine with running things directly from Windows programs, including the command prompt, unless you need extra environment settings provided by Cygwin to login shells. Since you're otherwise running things successfully apparently, don't worry about changing this part. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin git terminal won't capture password
On 4/7/2011 14:47, Faisal Memon wrote: Hi, When you use git from cygwin to clone a repo which requires a password, your password when typed comes out as plain text, instead of being taken from your terminal silently (without echo). The clone thus fails. The same local machine, but using linux command line shows the same repo working; it queries for password against the terminal session properly. snip I am using git in cygwin version 1.7.4. Cygwin is kicked off from the PuTTY program version 20101029 The same machine is running linux (via Virtual Box virtualisation), git version 1.7.1 I've seen this problem reported elsewhere (stackoverflow) but no solution. Any ideas what do to? Instead of using PuTTY to run Cygwin, try using mintty instead. It is available as a Cygwin package and is originally based on some fork of PuTTY if I recall correctly. Using a standard Windows cmd terminal will also work. I believe the problem is that Cygwin programs, such as git, expect to have a terminal when they prompt for passwords like that. Cygwin programs don't understand PuTTY as a terminal though. They probably see it as a plain pipe, so they won't try to treat it like a terminal and will thus be unable to capture passwords like this. You can see similar problems for native Windows programs that try to take input in a similar manner when running in a terminal such as mintty. Again, they see the terminal as a simple pipe, so it's impossible to do any of the terminal magic necessary to capture the password silently. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: EXTERNAL: Virus that deletes everything under c:/cygwin?
On 3/29/2011 08:30, Dante Allegria wrote: Thorsten Kampe wrote: Sure, it does. It's called intelligent scripting and it includes setting errexit and nounset in bash or Z Shell. If you are scripting and not using those above, then you got exactly what you deserved. Thanks for the tip, Thorsten! Any ideas what the best practice is for doing this in Makefile rules? It seems rather onerous to put this in *every* rule. Set the SHELLOPTS environment variable before calling make. Set each option you wish to enable in a colon separated list. Read the bash manpage for more details about that environment variable and the set builtin command. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Virus that deletes everything under c:/cygwin?
On 3/28/2011 09:43, Dante Allegria wrote: We just discovered that a whole bunch of our Windows machines had everything under their c:/cygwin directories deleted over the weekend. Has anyone else experienced this? Just trying to rule out some sort of malware/virus related to Earth Hour or perhaps some internal process gone awry. Just in case, check that your AV software didn't decide to quarantine things for some reason. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: EXTERNAL: Virus that deletes everything under c:/cygwin?
On 3/28/2011 12:07, Dante Allegria wrote: --- On Mon, 3/28/11, Damon Register damon.w.regis...@lmco.com wrote: this at a company. Is that so? Do you have an aggressive IS department who might have decided they don't like Cygwin? No, turns out it was because someone committed this into the nightly build scripts: rm -rf $(DOES_NOT_EXIST)/* sigh Should cygwin's rm have some built-in safeguards for this? :) Probably the only way to get this protection would be to remove the ability of the user running your build automation to delete the Cygwin installation in the first place. Otherwise, this could just as easily happen somewhere else such as a Perl script that doesn't even use rm. Depending on your situation, that may be easier said than done unfortunately. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ps command (process status) does not return anything anymore
On 3/28/2011 13:04, Antha Lamus wrote: Hi all, I recently installed a newer version of bash and now the ps command does not issue anything anymore (return code is 128). in fact, even the options seem different as I don't see -W in the man anymore. also, I can pretty much issue anything I want after the ps, like ps -dfiaodsfpaidfjasdfaf and it will simply return nothing ($?=128 still). I've tried to search through the archives but i guess ps is a bit to common! anybody has any idea what could have gone wrong? any place where I could check logs? Your Cygwin installation is probably only partially updated, perhaps because you had some Cygwin processes running the last time you performed an upgrade. Try rebooting the system to see if that clears things up. You can also run the following to see if any DLLs are missing: cygcheck /usr/bin/ps You might also need to file a more detailed report as documented here: http://cygwin.com/problems.html -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Migrating home dir
On 3/18/2011 10:28, Tod wrote: I'm going to be migrating to win7 in a few weeks. When I do I'll be logging in with a different userid. What's the best way to migrate my existing install and home dir to the new userid? My recommendation is that you back up only your Cygwin home directory contents, perhaps even with Cygwin's zip program. Then install a fresh Cygwin installation on the new system. Finally extract the home directory backup to your new Cygwin home directory. Speaking from personal experience, trying to transplant an existing Cygwin installation wholesale can be tricky and error prone, and it is not a supported operation for installation. You should avoid that if possible. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How do I make a COM port in windows accessible using cygwin?
On 3/17/2011 08:22, Vinod Pillai wrote: Vaclav Haisman wrote: Vinod Pillai wrote, On 15.3.2011 21:03: Im sorry but Im a complete novice at this. I cd-ed into the /dev folder. But I could not find a ttyS1. If you could elaborate what exactly I must do, it would be helpful. Thank you. Read the page I have linked: These devices cannot be seen with the command ls /dev/ although commands such as ls /dev/tty work fine. When I typed ls /dev/tty, I did not get any response. Any other possible solutions The command ls /dev/tty works for me: $ ls -l /dev/tty crw--w 1 jeremyb Domain Users 5, 0 Mar 17 08:43 /dev/tty Even if the path you attempted to use didn't exist, you should have got /some/ response: $ ls /dev/nonexistent ls: cannot access /dev/nonexistent: No such file or directory Can you provide more details about what exactly happened when you tried to run your command? -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Autostart Cygwin on Windows boot and run a cygwin command
On 3/14/2011 13:10, Jeremy Bopp wrote: bash -c cd /cygdrive/e/solr/apache-solr-4.0-2010-10-12_08-05-48/example/;java -Dsolr.solr.home=\./example-DIH/solr/\ -jar start.jar I forgot to append the trailing quote on the above command. It should be as follows: bash -c cd /cygdrive/e/solr/apache-solr-4.0-2010-10-12_08-05-48/example/;java -Dsolr.solr.home=\./example-DIH/solr/\ -jar start.jar -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Autostart Cygwin on Windows boot and run a cygwin command
On 3/14/2011 09:07, PeterSmith wrote: Sometimes my Windows server reboots at night to install new updates. Then the next day I find out that my cygwin instance has been stopped. What I want is on Windows start, also run Cygwin AND run a specific command. so, step 1: Right now I have a cygwin.bat to start cygwin: @echo off C: chdir C:\cygwin\bin bash --login -i step 2 is to enter the command in the command windows that appears after running cygwin.bat: cd /cygdrive/e/solr/apache-solr-4.0-2010-10-12_08-05-48/example/;java -Dsolr.solr.home=./example-DIH/solr/ -jar start.jar But this command is what I want to have called automatically when i run cygwin.bat How can I combine step 1 and step 2 into a single bat file which I can run on Windows start? While not 100% clear, I'm going to assume from your description that you actually want this to run when you log in rather than when the machine boots up. It also looks like you know how to handle that part yourself. Ask about setting up a service if you would like this to run independently of whether or not you ever log into the machine though. I tried this code: @echo off C: chdir C:\cygwin\bin bash -c cd /cygdrive/e/solr/apache-solr-4.0-2010-10-12_08-05-48/example/;java -Dsolr.solr.home=./example-DIH/solr/ -jar start.jar But that doesnt work... You need to help us help you here. Simply saying that something doesn't work without including any further details about what you see or error messages you receive forces us to guess about the problem. My guess about your problem is that your bash command is flawed. The -c option takes a single string that will be run as a command, and since your command has spaces in it, you need to quote it. Otherwise, the command will be split on those spaces which will lead to erroneous arguments for bash. Because your command also has quotes, you'll need to escape those with backslashes if you absolutely must keep them. Maybe something like this will work for you: bash -c cd /cygdrive/e/solr/apache-solr-4.0-2010-10-12_08-05-48/example/;java -Dsolr.solr.home=\./example-DIH/solr/\ -jar start.jar If you still have problems, please provide more details. :-) -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Autostart Cygwin on Windows boot and run a cygwin command
On 3/14/2011 13:25, PeterSmith wrote: FYI, this list prefers bottom posting rather than top posting. Reformatting... :-) Jeremy Bopp-3 wrote: bash -c cd /cygdrive/e/solr/apache-solr-4.0-2010-10-12_08-05-48/example/;java -Dsolr.solr.home=\./example-DIH/solr/\ -jar start.jar If you still have problems, please provide more details. :-) First of: sorry for not providing all info. I DO want to run this command as soon as my machine boots. My server sometimes reboots at night after an update. So when Windows starts, in the Startup Folder I will place a shortcut to the .bat file. What Startup Folder are you talking about exactly? I'm probably just not aware of such a folder whose contents are executed by the system upon boot up, but if you're talking about the folder for your user account, that will only be run when you log in. If your machine automatically logs you in on boot up, you'll be fine in that case; otherwise, you'll need to hook this up a bit differently. You may want to look into the Registry: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run I'm not sure if you can directly run a batch file there or if you'll have to run cmd with the batch file as an argument. Assuming this works for you, the only problem then will likely be that this will run as the Local System account rather than your user, which may or may not matter to you. I the bat file I now have: @echo off C: chdir C:\cygwin\bin bash -c cd /cygdrive/e/solr/apache-solr-4.0-2010-10-12_08-05-48/example/;java -Dsolr.solr.home=\./example-DIH/solr/\ -jar start.jar I forgot to include the final quote in my first reply. Try again with a quote at the end of that last line. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Autostart Cygwin on Windows boot and run a cygwin command
On 3/14/2011 14:21, PeterSmith wrote: Ok, so for now lets focus on the contents of the .bat file. I'll have a look at the startup of the bat later :) Excellent idea, especially considering that it's not really a Cygwin problem at that point. ;-) I now have this: @echo off C: chdir C:\cygwin\bin bash -c cd /cygdrive/e/solr/apache-solr-4.0-2010-10-12_08-05-48/example/;java -Dsolr.solr.home=\./example-DIH/solr/\ -jar start.jar But that still gives me the exact same error: C:\start_cygwin.bat bash: line 0: cd: /cygdrive/e/solr/apache-solr-4.0-2010-10-12_08-05-48/example/: No such file or dir ectory Unable to access jarfile start.jar C:\cygwin\bin I think the Unable to access... error message is actually coming from java.exe. That's likely because the cd before the java call failed first, so you're not in the directory you expect to be when java is started. Make sure you don't have a typo in that path to which you're trying to cd. You may also consider replacing the ; in the command with so that the java command is never run if the cd fails. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: git/ssh problem should be fixed
On 2/21/2011 12:12 AM, Christopher Faylor wrote: Thanks to some insight from Corinna, the git/ssh problem should be fixed in the latest Cygwin snapshot from http://cygwin.com/snapshots/ . I can no longer reproduce the problem documented in the message below using the latest snapshot: http://cygwin.com/ml/cygwin/2010-07/msg00505.html Thanks for your hard work, cgf! -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Accessing folders elsewhere than C:\cygwin
On 02/09/2011 08:42 AM, Fergus wrote:
I have Cygwin mounted conventionally under Q:\cygwin.
I would like to access files under Q:\else.
But (for example) ls ../../.. only ever attains \cygwin (and lower).
I can use ls /cygdrive/q/else/ (and lower) but this means knowing the
drive name (in this case Q:)
I don't much want to change mount points which are currently
conventionally defined.
Is there a way I can get to Q:\else without knowing the drive name Q:?
If creating a new mount in addition to your standard mounts is out of
the question (not sure if that's what you meant), you could add
something like the following to your .bashrc or .bash_profile file:
function else_path {
cygpath -u $(cygpath -m /)/../else
}
Then you could refer to the path as follows:
ls $(else_path)
cd $(else_path)
Another option would be to create a temporary mount within one of your
startup files:
mount | grep -q 'on /mnt/else type' ||
mount $(cygpath -m)/../else /mnt/else
Now you can access Q:\else as /mnt/else. If you decide you would like
to make a more permanent mount but just for your user, you can read in
the Cygwin Users Guide for how to set that up in a file under
/etc/fstab.d/. Of course, you can also make the mount available to all
users by adding it to /etc/fstab. :-)
-Jeremy
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Accessing folders elsewhere than C:\cygwin
On 02/09/2011 09:50 AM, Jeremy Bopp wrote: mount | grep -q 'on /mnt/else type' || mount $(cygpath -m)/../else /mnt/else ^^^ I lost a slash in the above code. It should be as follows: mount | grep -q 'on /mnt/else type' || mount $(cygpath -m /)/../else /mnt/else -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How to detect CygWin SVN?
On 02/09/2011 01:10 PM, Jochen Wiedmann wrote: Hi, I'd like to write a script, which ought to work with the CygWin SVN client as well as any native SVN clients. As a prerequisite, I need to detect whether the svn program in the path is CygWin SVN or not. Question is, how to do this? Because the output of svn --version contains nothing that indicates compilation with CygWin. I'm assuming that your script expects svn to be in the PATH, so you could check to see if the path to the svn client lives within Cygwin's installation: if [ $(type -p svn) = '/usr/bin/svn' ]; then echo Found Cygwin's svn client fi Unless someone goes out of their way to confound things, this should be good enough. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How to detect CygWin SVN?
On 02/09/2011 02:22 PM, Jochen Wiedmann wrote: On Wed, Feb 9, 2011 at 8:17 PM, Jeremy Bopp jer...@bopp.net wrote: I'm assuming that your script expects svn to be in the PATH, so you could check to see if the path to the svn client lives within Cygwin's installation: if [ $(type -p svn) = '/usr/bin/svn' ]; then echo Found Cygwin's svn client fi Unless someone goes out of their way to confound things, this should be good enough. Thanks for the idea. However, I'd prefer a solution that works with the native cmd-Shell too. Otherwise, I'd assume that CygWin is installed. Since you want a solution that works in either environment, in what language are you going to implement your script? You can do something very similar in Perl and other such languages, but I can't think of a single method that would work in both bash and cmd without at least some syntax tweaks. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.7: window cuts off output / saving output
On 2/2/2011 10:13 AM, Rachel Trent wrote: I have a seemingly simple problem that I either haven't found the answer to or I didn't understand the answer when I saw it. I presume I'm not describing it with the correct terminology... Short version: In layman's terms, the Cygwin window cuts off at the top, and I'd like to know if the output that's been cut off is forever lost or if I might be able to save it to a file or view it some other way. The exact solution for increasing your scrollback buffer is dependent upon the terminal you're using. If you're using mintty, you can find the option in the Options dialog within the Window section. If you're using the Windows cmd terminal, and it sounds like you are, you can find the option you need in the Properties dialog on the Layout tab. Change the height of the screen buffer to whatever you need. All of that is just a quick hack though because you could always have output that is longer than your scrollback buffer. What follows is not Cygwin-specific, but you don't seem to know about this stuff yet. If you need to be sure to always have your command's complete output available, you need to redirect its output to a file. e.g.) create_output --lots-of-it out.log If you would like to see the output as it goes by and still save it all, pipe your command's output to the tee program and give tee the path to a file as an argument into which the output will also be recorded. e.g.) create_output --lots-of-it | tee out.log Now you can review out.log at your leisure using a text editor or a simple pager. You can also just send the output to a nice pager such as less if you don't mind interacting with the pager a bit in order to let your command complete. e.g.) create_output --lots-of-it | less -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.7: window cuts off output / saving output
On 2/2/2011 10:44 AM, Jeremy Bopp wrote: All of that is just a quick hack though because you could always have output that is longer than your scrollback buffer. What follows is not Cygwin-specific, but you don't seem to know about this stuff yet. Sorry to reply to myself, but I just realized that you *do* know about the tee program. That's what I get for being too aggressive with pruning quoted messages. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ssh-keygen command not doing anything OR github problem
On 2/2/2011 2:29 PM, mearrex wrote: However, when I type in the commands ssh ssh-keygen ssh-keygen -t rsa -C xxx...@xxx.com ssh g...@github.com ssh -v g...@github.com nothing happens. It just returns a new line. I am attaching a screenshot. What am I doing wrong? What do I need to do to get this to work? My guess is that your Cygwin installation is incomplete or corrupted. Follow these instructions to provide the Cygwin developers the information they need to help you out: http://cygwin.com/problems.html -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Windows 2008 64-bit install
On 2/2/2011 3:11 PM, Bryan Slatner wrote: Thorsten Kampe thorsten at thorstenkampe.de writes: I'd just delete everything and do a fresh minimal installation. If this fails again, you can continue here. First check http://cygwin.com/faq/faq.using.html#faq.using.bloda I'll do my best, but my order of operations when I got the failure was: 1) Spin up a brand new EC2 Windows 2008 64-bit instance 2) Log in 3) Install Cygwin I literally did nothing else. So, if there is some dodgy software causing an issue, I may not have the luxury of uninstalling it. I haven't tried it myself, but I am told the same does NOT happen on a 32-bit W2K8 instance. Could this be related to this earlier thread? http://cygwin.com/ml/cygwin/2010-09/msg00212.html -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Where to find a reliable provider of CygwinX?
On 2/1/2011 3:10 PM, Jørgen Steensgaard wrote: Another experience that emerge from this discussion is that it seems very hard to be believed. It is also very hard to document the details of what goes on during installation. Please take than into account when you take this as a support experience, which certainly is in line with my intentions. Many if not most of setup's actions are recorded in log files in the /var/log directory of your Cygwin installation. Take a look at the setup.log and setup.log.full files. Among the information provided there are the mirror(s) and package(s) you selected. There are also error messages which could be relevant to this discussion. Unfortunately, I think the files are blown away and rewritten every time you run setup.exe. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gfortran, lapack, and cygwin
On 2/1/2011 3:41 PM, Timothy Sliwinski wrote: I am using the following command for my compilation: $ gfortran test.for –o test –llapack And the error I receive is /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: cannot find -llapack collect2: ld returned 1 exit status Make sure that you install the liblapack-devel package. I think you'll need that for compiling your code, but I'm no fortran user. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: vim wraps lines
On 01/26/2011 09:20 PM, Mike Brown wrote: On Wed, Jan 26, 2011 at 10:12:01PM -0500, Larry Hall (Cygwin) wrote: On 1/26/2011 12:00 PM, Daniel Ajoy wrote: I'm using the latest cygwin, min-tty and vim But when I open vim, lines seem to wrap. Here is the image: http://i.imgur.com/oC8lo.png Is that a configuration issue? how do I fix it? IMHO it isn't broken. That is the expected behavior. That is how I use it and I want to see all of the line, even if it wraps. Why don't you want to see all of the line? Mike, please take another, closer look at the linked image. It's clear that what is displayed is the initial text outputted by vim when started without a file to open and that the display of this text obviously broken. While the problem could have been worded differently to avoid the confusion, the image makes the problem unambiguous. It's most likely a problem with the TERM setting in use when vim was started, as Larry asked to clarify. I think it's also possible that a non-Cygwin version of vim was actually started under a Cygwin session. Larry's suggestion to follow the problem reporting guidelines would likely clarify this point as well. BTW, if you didn't intend to comment on Larry's reply at all, you should have replied to Daniel's message instead. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: failing to clone a git repo via ssh
On 01/23/2011 06:21 AM, Rafael Kitover wrote: I just realized this bug is replicatable without having ssh access to our repo, you just need the cygwin sshd enabled, and the guy with access to the gitosis went off somewhere anyway... Here are the steps: cd ~ mkdir tmp cd tmp git clone git://git.shadowcat.co.uk/dbsrgits/DBIx-Class.git dbic_git_url git clone `whoami`@localhost:tmp/dbic_git_url dbic_ssh Sadly, the early EOFs problem is an identified but unfixed issue: http://cygwin.com/ml/cygwin/2010-07/msg00413.html http://cygwin.com/ml/cygwin/2010-10/msg00044.html Since my last report in that thread, I did try a few other configurations: * msysGit with msysGit's ssh * msysGit with Cygwin's ssh * Cygwin's git with msysGit's ssh All of these combinations avoided the early EOFs problem no matter how many times I repeated my testing. As cgf said, this does appear to be a problem in Cygwin's pipe code, but it's very strange that it only seems to be triggered with Cygwin's git + Cygwin's ssh. My guess is that there is some kind of race condition in the pipe setup code when both ends of the pipe are Cygwin processes, but I'm admittedly unfamiliar with Cygwin's pipe code. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: failing to clone a git repo via ssh
On 01/23/2011 01:37 PM, Steven Hartland wrote: - Original Message - From: Jeremy Bopp jer...@bopp.net All of these combinations avoided the early EOFs problem no matter how many times I repeated my testing. As cgf said, this does appear to be a problem in Cygwin's pipe code, but it's very strange that it only seems to be triggered with Cygwin's git + Cygwin's ssh. My guess is that there is some kind of race condition in the pipe setup code when both ends of the pipe are Cygwin processes, but I'm admittedly unfamiliar with Cygwin's pipe code. Possibly the same issue which still plagues rsync under cygwin? I've thought the same thing myself, but I don't have any test cases for that and haven't experienced the problem directly. As I recall, the rsync case manifests as a hang which seems a bit different than this case of unexpected EOFs. It's possible that it could be rsync's reaction to the unexpected EOF could mask it as a hang, I suppose. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: windows paths in shebang lines
On 01/23/2011 03:47 PM, Rafael Kitover wrote: When a script's shebang line has a windows path, rather than a cygwin path, it does not work: rkitover@eeebox ~ $ head -1 /cygdrive/c/Perl64/site/bin/ack #!C:\Perl64\bin\perl rkitover@eeebox ~ $ /cygdrive/c/Perl64/site/bin/ack --version Can't open perl script /cygdrive/c/Perl64/site/bin/ack: No such file or directory On msys (msysGit) this works correctly: rkitover@EEEBOX ~ $ /c/Perl64/site/bin/ack --version ack 1.94 Running under Perl 5.12.2 at C:\Perl64\bin\perl.exe Copyright 2005-2010 Andy Lester. This program is free software. You may modify or distribute it under the terms of the Artistic License v2.0. Any chance this could be fixed? This would be a very nice feature for users of Strawberry Perl and similar. The problem is not that you're using a Windows path instead of a Cygwin path in the shebang line; although, that is not officially supported under Cygwin. Rather, the problem is that the version of Perl being run as a result of that shebang line does not understand Cygwin paths. That's why you see this error: Can't open perl script /cygdrive/c/Perl64/site/bin/ack: No such file or directory That's the Perl interpreter telling you that it doesn't understand the path that was given to it for the ack script, so Perl is running at this point which means that the shebang line is understood correctly. You should probably go read about how shebang lines work in general, but the short and sweet is that the shebang line is the first part of a command line to be run where the last part is the command line used to run the file that contains the shebang line itself. IOW, the command line used in your first example is ultimately: C:\Perl64\bin\perl /cygdrive/c/Perl64/site/bin/ack --version You have 3 potential solutions to your problem: 1) Run Perl explicitly with the Windows path to the script as an argument: /cygdrive/c/Perl64/bin/perl C:/Perl64/site/bin/ack 2) Change into the C: drive and use a relative path to the ack script when you run it: cd /cygdrive/c Perl64/site/bin/ack 3) Change your cygdrive mount location to / so that the path to the ack script will be /c/Perl64/site/bin/ack under Cygwin. Option 3 is the real hack. I think it should work because it appears in your successful example that the Perl you want to use is able to translate paths such as /c/path/to/something to C:/path/to/something internally. By adjusting the cygdrive mount location to /, you will cause Cygwin to send a compatible path to Perl when you run the script as /c/Perl64/site/bin/ack. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Invoking GUI programs over SSH
On 1/17/2011 3:20 PM, David Antliff wrote: Hello, I've found this thread so far: http://cygwin.com/ml/cygwin/2010-07/msg6.html It's related to what I am trying to do, but I'd like to get confirmation that what I am attempting is impossible, or not. Essentially I have a seemingly command-line based FPGA synthesis tool (a compiler if you prefer) called Synplify Pro. Unfortunately it is not truly command-line, but does some sort of GUI-related operations even though it shows no actual GUI (except sometimes a splash screen). This means that although I can run it from a local bash instance, and it will run, I don't seem to be able to run it from an SSH session. Copyright (c) 1991-2010 Lattice Semiconductor Corporation, All rights reserved. Failed to get 'Config' context string of ispLever System Failed to get 'Root' context string of ispLever System The reason I want to do this is because I'm using the Hudson Continuous Integration server to create a cluster of build machines. Hudson uses SSH to connect to Slave nodes and run processes. A build using Synplify Pro will work on the 'master' node, but does not work on any Slave node because of the above error. I believe it needs access to GUI services to run correctly. I noticed when I run Windows apps such as notepad.exe or calc.exe over SSH that they start up, no GUI appears, but as far as I can tell they remain running. Note that I do not want the GUI to appear on the remote computer - I understand that is an entirely different proposition and I'm not interested in this. I just want the program to think it can open the GUI and not abort with an error message. Does anyone know of any 'trick' to enable a GUI program to work via SSH please? I'm using Cygwin 1.7.5 on Windows XP SP3 32bit. Perhaps you could use the editrights program to add the SeInteractiveLogonRight for the user running the ssh service and effectively get access to the main desktop that way. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Invoking GUI programs over SSH
On 1/17/2011 3:46 PM, David Antliff wrote: I just tried this - in fact I used the AdministrativeTools/Services applet to set the Cygwin SSHD service to Allow service to interact with desktop. This actually had a useful effect - I can now start 'notepad' or 'calc' and I see the process appear on the main desktop. However, unfortunately, I still get the same error from Synplify Pro. I wonder if it's looking for more than just GUI services? Yeah, the error message you described originally didn't sound like a problem with starting the GUI. The message really looks like it's failing to read some configuration information. Maybe there is some strange permission on an important registry setting or a file that is preventing the authenticated account from accessing the necessary information when logging in through SSH. Is it possible that Synplify Pro is attempting to access some network resource or a special dongle for verifying its registration or something similar? Also, having that option set causes any SSH connection attempts *from Cygwin* to connect, then immediately terminate. However if I connect from a Linux host, it connects fine. If I turn off the Allow service to interact with desktop, then I can connect again. Not a big deal, but odd. Someone else would have to explain that one. It's definitely odd that it only affects a Cygwin-based SSH client. Maybe there is some detail in /var/log/sshd.log. I've also tried running the sshd service as the same user currently logged in (i.e. running the desktop). However when I do this, the sshd service fails to start with no error message other than service could not be started. The service did not report an error. There is more than one thread about this in the list archives. The summary is that you'll most likely fail to do this right unless you're a serious expert in Cygwin, SSH, and Windows permissions. Furthermore, people are discouraged from attempting it and then asking for help making it work or undoing what they did. The solution I've seen most often is essentially reinstall Cygwin from scratch and use ssh-host-config. It's possible that you'll find more details concerning the failure in the /var/log/sshd.log file. You can probably also examine the ssh-host-config script to see how it goes about configuring things for the account it uses by default. Have you tried contacting Synplify Pro's author/distributor to see if they have suggestions for automating its use as you're attempting? -Jeremy signature.asc Description: OpenPGP digital signature
Re: Invoking GUI programs over SSH
On 01/17/2011 05:06 PM, David Antliff wrote: On Tue, Jan 18, 2011 at 11:06, Jeremy Bopp wrote: Is it possible that Synplify Pro is attempting to access some network resource or a special dongle for verifying its registration or something similar? There's no dongle but there is a license server it needs to communicate with. I'll investigate that, although based on experience it usually just blurts out no license, goodbye. I'll check permissions as well. You might also want to try to figure out what rights your shell process has when run locally vs. remotely over SSH. I also believe there are some potentially significant differences when logged in remotely depending on whether you use password vs. pubkey authentication. I don't have a Windows system nearby at the moment, but I would guess that there should be a counterpart to editrights that will show you the current rights assigned. Maybe someone else will be able to name the tool if it exists before I get back to my work computer tomorrow. Do you know if there is an equivalent tool to 'strace' for Windows that I can use to log all syscalls/file/resource accesses made by a program and its threads? I think you'll want to try Sysinternals Process Monitor: http://technet.microsoft.com/en-us/sysinternals/bb896645 I haven't used it before, but I have used its predecessors RegMon and FileMon. They can generate copious amounts of information and filter that information fairly granularly, so this newer tool should be able to do so as well. It's a GUI tool though, so you'll likely have to start it running locally prior to running your remote access tests. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin windows 7 path environment variable.
On 12/15/2010 05:26 AM, sean rankin wrote: I am trying to set the path vaiable for the cygwin compiler to use with netbeans IDE. i can't seem to find anywhere on the website the specific path that i need to put in to get it to run. can you please email the the correct path? Usually, all you need to add to PATH is the path to the bin directory of your Cygwin installation. By default that path is C:\cygwin\bin. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem installing packages
On 12/11/2010 10:26 PM, Jeffrey Walton wrote: Hi All, According to http://www.cygwin.com/, Run setup.exe any time you want to update or install a Cygwin package. : jeff...@descartes ~ $ setup.exe Result is a message box that states Please go to the Control Panel to install and configure system components. Navigate to Control Panel - Add/Remove Programs. Cygwin is *not* listed. I'm obviously doing something wrong. Any ideas where my ability (or lack of) to follow instructions failed? It sounds like something other than Cygwin's setup.exe is being run. You seem to be attempting to run setup.exe from within bash, and if so, the current working directory (where you likely have Cygwin's setup.exe) is not a part of your PATH. That means that you need to invoke setup.exe as ./setup.exe. Keep in mind that you should usually avoid running setup.exe while Cygwin processes (such as bash) are running. If setup updates a package whose files are in use, you'll be forced to reboot in order to complete the setup process, and it's possible that you'll have a rather broken Cygwin installation until you do so. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Permissions on Windows 2008
On 12/09/2010 03:38 PM, Bryan Slatner wrote: Jeremy Bopp jeremy at bopp.net writes: By default Cygwin tries to emulate POSIX file permissions: http://cygwin.com/cygwin-ug-net/ntsec.html You can disable this by modifying your /etc/fstab file and adding the appropriate options to cause the target locations for your files to have the necessary options: http://cygwin.com/cygwin-ug-net/using.html#mount-table Specifically, you may need to modify the settings for the cygdrive mountpoint: http://cygwin.com/cygwin-ug-net/using.html#cygdrive Jeremy, I guess I spoke too soon. I'm not really sure which fstab options are appropriate here. Are you suggesting modifying the cygdrive mount, or adding a new one with some different options? I'm not really clear how to proceed here or which are the relevant options. Take a look at the noacl option. You'll want to apply that to whatever mountpoint contains the target path of your copy operation. If you want to be surgical in the application, create a new mountpoint with this option set and copy your files into paths within it. Otherwise, you can apply it to the cygdrive mountpoint so that the option applies to any path under /cygdrive and UNC paths. I'm not sure if it's possible to change the mount options of /, /usr/bin, or /usr/lib since those mountpoints are implicitly defined. Setting this option on them would probably break things anyway. If your target path is currently something like /home/whatever, set up a new mountpoint with the noacl option and copy to that instead. -Jeremy signature.asc Description: OpenPGP digital signature
Re: setup from a list of packages rather than interactive selection?
On 12/10/2010 09:32 AM, Lee D. Rothstein wrote:
I vaguely remember a discussion, here, about how to install using
'setup.exe' from a list of packages contained in a file which is
then pointed to on the command line. I see the '-p' option in
'setup', and although I know how to put the list ('Pkg_List.txt')
after the -p in bash (i.e. '-p \$(cat Pkg_List.txt)\), I don't know
how to do this in 'cmd.exe'.
I've tried Googling, but to no avail.
I've also tried using the '-d' option in 'cygcheck' to create the
list for my current configuration, but that doesn't seem to work.
I've tried Googling on this issue, as well, also to no avail.
I think I remember what you're talking about. Will it work with '-p
@Pkg_List.txt'? I want to think that the @ hack is not a feature of cmd
but rather of the Cygwin DLL, but maybe setup respects it as well. I
don't have a Windows system at hand to try this myself.
-Jeremy
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Getting Bounce Messages
When sending replies to this list, I'm getting bounce messages for a single email address that is apparently subscribed to the list but no longer valid: The original message was received at Fri, 10 Dec 2010 15:41:09 GMT from gw-out.ccsw.co.uk [78.33.22.223] - The following addresses had permanent fatal errors - expired-cbsa01 AT publix.bangor.ac.uk (reason: 550 5.1.1 User unknown) (expanded from: cbsa01 AT bangor.ac.uk) - Transcript of session follows - 550 5.1.1 expired-cbsa01 AT publix.bangor.ac.uk... User unknown From deeper in the bounce message, the actual recipient appears to be llio AT testun.co.uk. Is anyone else getting these bounce messages? -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: skipping initial setup screens for existing installation with setup.exe?
On 12/7/2010 1:43 PM, Steven Lefevre wrote: When I want to install a new package in my existing cygwin installation, I fire up setup.exe and blow through the first couple screens that ask me about installation directory, mirrors, packages directory, etc, to get to the package installation menu. Is there a way I can skip those initial setup screens and go straight to package selection once I have my installation going? Run setup.exe --help for a full list of command line options. The option you want is -M. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: skipping initial setup screens for existing installation with setup.exe?
On 12/7/2010 2:08 PM, Andrey Repin wrote: If this normal for setup ? $ ./setup.exe --help Starting cygwin install, version 2.721 io_stream_cygfile: fopen(/etc/setup/extrakeys) failed 2 No such file or directory io_stream_cygfile: fopen(/etc/setup/chooser_window_settings) failed 2 No such file or directory Current Directory: \\DAEMON1\arc\cygwin\install Command Line Options: -D --download Download from internet -L --local-install Install from local directory -s --site Download site -O --only-site Ignore all sites except for -s -R --root Root installation directory -P --packages Specify packages to install -C --categoriesSpecify entire categories to install -p --proxy HTTP/FTP proxy (host:port) -q --quiet-modeUnattended setup mode -M --package-manager Semi-attended chooser-only mode -h --help print help -l --local-package-dir Local package directory -r --no-replaceonrebootDisable replacing in-use files on next reboot. -X --no-verify Don't verify setup.ini signatures -n --no-shortcuts Disable creation of desktop and start menu shortcuts -N --no-startmenu Disable creation of start menu shortcut -d --no-desktopDisable creation of desktop shortcut -K --pubkeyPath to extra public key file (gpg format) -S --sexpr-pubkey Extra public key in s-expr format -u --untrusted-keysUse untrusted keys from last-extrakeys -U --keep-untrusted-keys Use untrusted keys and retain all -A --disable-buggy-antivirus Disable known or suspected buggy anti virus software packages during execution. Ending cygwin install AddAccessAllowedAce(, owner) failed: 1337 AddAccessAllowedAce(, group) failed: 1337 AddAccessAllowedAce(, everyone) failed: 1337 AddAccessAllowedAce(, owner) failed: 1337 AddAccessAllowedAce(, group) failed: 1337 AddAccessAllowedAce(, everyone) failed: 1337 That's the output I see when running under cmd, and I have to hit Enter to get the prompt back. That same command under bash works great though. I suspect I have to hit Enter by design so that if someone ran setup --help with a shortcut they would have a chance to see the output before the cmd window closed. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: skipping initial setup screens for existing installation with setup.exe?
On 12/7/2010 2:03 PM, Steven Lefevre wrote: On Tue, Dec 7, 2010 at 2:47 PM, Jeremy Bopp jer...@bopp.net wrote: Run setup.exe --help for a full list of command line options. The option you want is -M. Hello Jeremy - Thanks for your help :) I had tried the -M option, but got no window. Perhaps there's another problem that's causing my symptoms. You should see a window, so that's odd. I'm using Windows Vista. I have a shortcut on the desktop that launches setup.exe. I've tried both the -M and --help switches, with and without 'Run As Administrator' checked, but I get no window. However, the shortcut works ( the window appears with the initial screen) when I remove the switches. I also tried the switches in cmd, both as and not as Administrator, also with no windows appearing. But again, the setup window launches okay when I use no switches. I wish I could help more, but I don't have a Vista installation on which to try this. It *should* work though. The setup maintainer should be able to give you more detailed pointers once he sees the thread. Something to look for are the log files setup creates when running: http://cygwin.com/faq/faq-nochunks.html#faq.setup.setup-fails Perhaps those logs have useful information. Also I had noticed that the -M switch is not listed in the FAQ http://cygwin.com/faq/faq-nochunks.html#faq.setup.cli Good catch. I'm not sure of the exact procedure, but I believe that a patch with the updated information would be accepted. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Permissions on Windows 2008
On 12/06/2010 11:09 PM, Bryan Slatner wrote: I've just installed Cygwin on a Windows 2008 Standard server with SP2. I'm noticing two strange behaviors with files that I upload via SFTP (or SCP, I'm not actually sure which protocol WinSCP uses by default). First, the ACL list on the uploaded files contains an entry for ServerName\None, which is a non-existent account as best I can tell. Second, it shares the files and directories using the Windows 2008 file sharing feature that allows you to share files with other users on the same machine. It shares the file with Everyone and ServerName\None. Both of these are undesirable behaviors. Ideally, I would like files uploaded with SFTP to have the same permissions they'd have as if I had just created them in place. The sharing thing is particularly annoying because if I start moving files around, Windows frequently pops up a warning like Warning: These files are shared. If you move them, they will no longer be accessible. Any tips on how to prevent these behaviors would be welcome. By default Cygwin tries to emulate POSIX file permissions: http://cygwin.com/cygwin-ug-net/ntsec.html You can disable this by modifying your /etc/fstab file and adding the appropriate options to cause the target locations for your files to have the necessary options: http://cygwin.com/cygwin-ug-net/using.html#mount-table Specifically, you may need to modify the settings for the cygdrive mountpoint: http://cygwin.com/cygwin-ug-net/using.html#cygdrive -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.5: fixing git damage
On 11/22/2010 4:06 PM, Bill Ross wrote: I just tried this sequence with my cygwin git: $ git checkout master $ git pull $ git checkout my_branch error: Untracked working tree file 'java/api_client/test/xls/qa2/QA2WWWKeyword.xls' would be overwritten by merge. $ git --version git version 1.7.1 -bash-3.2$ git status # On branch master # Untracked files: # (use git add file... to include in what will be committed) # # test/xls/qa2/QA2WWWKeyword.xls *** What I am looking for is a solution to this: -bash-3.2$ mv test/xls/qa2/QA2WWWKeyword.xls /cygdrive/c/tmp mv: cannot move `test/xls/qa2/QA2WWWKeyword.xls' to `/cygdrive/c/tmp/QA2WWWKeyword.xls': Device or resource busy -bash-3.2$ rm test/xls/qa2/QA2WWWKeyword.xls rm: cannot remove `test/xls/qa2/QA2WWWKeyword.xls': Device or resource busy It looks like you might have that spreadsheet opened in Excel. Make sure the file is not open under any program. Then you should be able to move or delete it. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: File format problem after updatin to 1.7.1 - solved
On 11/17/2010 09:55 PM, Paul wrote: Jeremy Bopp jeremy at bopp.net writes: http://cygwin.com/cygwin-ug-net/using.html#mount-table Now that I'm looking specifically for this issue in the linked documentation, I see that there *is* a way to override the root mountpoint clearly described there. Well Jeremy, it would have been helpful and accomodating of you to have jotted down the relevent info in the reply, rather than just simply saying I know. Well, Paul, I referred to the official source of information in the hopes that the list archives would not be polluted with contradictory information if those details ever change again. It's not as if following the link and reading the documentation is particularly difficult. It certainly wasn't an attempt to be unhelpful or obtuse, but you can go on believing whatever you like. Have fun opening other old threads and chastising random people. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [patch 2/8] Document EXECIGNORE in Cygwin readme
On 11/2/2010 3:48 PM, dan.colasci...@gmail.com wrote: Index: bash-3.2/CYGWIN-PATCHES/bash.README === --- bash-3.2.orig/CYGWIN-PATCHES/bash.README +++ bash-3.2/CYGWIN-PATCHES/bash.README @@ -55,7 +55,14 @@ is on a binary mount with igncr disabled would be text mounts with igncr disabled and no \r in the underlying file. Next would be binary mounts with igncr enabled. And the slowest that bash will operate is on text mounts with igncr enabled. -8. If you don't like how bash behaves, then propose a patch, rather than +8. This version of bash has a new special variable EXECIGNORE. It is a +colon-separated list of extended glob patterns. If a file's full path +matches one of these, it is no considered executable for the purposes ^^ That should be not instead of no. +of completion and PATH searching. The `test', `[', and `[[' builtins +are not affected. Use this variable to prevent non-executables +uselessly appearing in completion lists; EXECIGNORE=*.dll is quite +useful. +9. If you don't like how bash behaves, then propose a patch, rather than proposing idle ideas. This turn of events has already been talked to death on the mailing lists by people with many ideas, but few patches. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Connection timed out
On 10/30/2010 09:41 AM, KeithLaw wrote: 4. I modified the ssh_config as below. snip 5. I modified the sshd_config as below snip That's it for my settings but still cannot connect. Did you try any of this with default settings for sshd_config and ssh_config before making your modifications to them? If so, did you have these problems then too? -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Subversion mangling names in .svn/entries metadata file
On 10/26/2010 05:58 AM, J.C. Wren wrote: OK, I did several things. First, I downgraded subversion to 1.6.12 and everything worked. Then I re-ran the installer and re-installed the base cygwin package, which should have upgraded the DLL. It did not, It was still at 1.7.5. I'm using setup 2.721, http://mirrors.kernel.org for the site, the installer says the package installed is 1.7.7-1. I then manually deleted the cygwin1.dll and ran setup.exe again. THIS time it upgraded the DLL. The DLL's don't have any weird permission, so I don't know why it didn't upgrade. I did have sshd running, and setup threw a warning that I'd need to reboot. Maybe something related to that? Anyway, at this point, I now appear to be able to use subversion without filename mangling. I'm just curious why multiple installs of the cygwin base didn't update the cygwin1.dll. Very weird! Setup.exe warned you that a file was in use and then told you to reboot in order to complete your installation, and yet you think it's weird that your installation is incomplete without a reboot. Hmmm Anyway, this is a well known problem with Windows. Files that are in use, such as cygwin1.dll when sshd is running, cannot be immediately replaced. If you want to replace them, you must either ensure they are not in use (by stopping sshd and any other Cygwin process in this case) or schedule them to be replaced upon reboot (which is precisely what setup.exe does for you) and then actually reboot. :-) -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Subversion mangling names in .svn/entries metadata file
On 10/26/2010 8:11 AM, J.C. Wren wrote: Do you *really* think I didn't reboot it? C'mon now, be serious. I've been using Cygwin for at least 5 years, I think I can follow some instructions when setup tells me I'll need to. Sorry, but yes, that's what I thought. It's a common enough problem for people in a rush to get things running to skip a reboot. Perhaps you did skip a reboot at one point and things got a little wedged when you ran later instances of setup.exe. I'm not intimately familiar with the guts of setup.exe to know for sure whether or not that is possible though. Maybe I didn't explicitly say that I did reboot the system, but that's not a reason to merely assume that I didn't. On the contrary, I think it's a great reason to assume you didn't reboot given your description of how cygwin1.dll eventually got updated and the following quote: On 10/26/2010 05:58 AM, J.C. Wren wrote: I did have sshd running, and setup threw a warning that I'd need to reboot. Maybe something related to that? -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SSH - Can't Login (3rd Post)
On 10/26/2010 1:53 PM, Charles Smith wrote: I'm apparently having the same problem you are - when I run the ssh client, it gives me the usage output. I discovered that if I go back to the previous version (5.5p1.2?), it works. Every time I update with setup.exe, I have to go back and reset openssh to 5.5. I figured I must be doing something really stupid, until a colleague complained to me that ssh didn't work - when I told him about the 5.5 version, that solved his problem. This has been going on for months now. I do an internet search occasionally, but nothing comes up. I'm actually quite puzzled. Have you tried to confirm that you don't have an alias, shell function, or script named ssh that is masking the real ssh binary? Something like that could be calling the real ssh with some arguments that are invalid under the latest version. What do you get when you run the following: type -a ssh Have you tried installing a fresh copy of Cygwin to a new directory to see if the problem recurs in that instance? If the problem happens in one but not the other when they should be otherwise identical, a diff over the directories might track down the problem. If the problem happens in both places, maybe you have some other software installed on your system that is somehow interfering. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SSH - Can't Login (3rd Post)
On 10/26/2010 09:10 PM, Brian Wilson wrote: I have the same problem and have not been able to resolve the issue either. I get the following from the type -a command. Invoking either from the bash shell with a complete path still just displays the usage message and gives a return code of 255. Everything else seems to be working fine. A return code of 255 seems odd. Maybe a required DLL is missing. What is the complete usage message displayed? Brian S. wil...@ncc-1701 ~ $ type -a ssh ssh is /usr/bin/ssh ssh is /bin/ssh What is the output of the following: ls -l /usr/bin/ssh /bin/ssh ldd /usr/bin/ssh What happens when you invoke ssh from a cmd shell? -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How can I get mintty to not display my password?
On 10/22/2010 01:49 PM, risin...@nationwide.com wrote: When using cmd.exe, when I am prompted for a password, no characters are displayed, but the password gets entered. However, when I use mintty, the characters I type at the password prompt are displayed. TERM=xterm. How can I stop this from happening? In cmd.exe: --- sqlplus risin...@ctibeta2 SQL*Plus: Release 10.2.0.1.0 - Production on Fri Oct 22 14:38:07 2010 Copyright (c) 1982, 2005, Oracle. All rights reserved. Enter password: Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production With the Partitioning, Data Mining and Real Application Testing options SQL In mintty: -- sqlplus risin...@ctibeta2 SQL*Plus: Release 10.2.0.1.0 - Production on Fri Oct 22 14:38:07 2010 Copyright (c) 1982, 2005, Oracle. All rights reserved. Enter password: hereISmyPASSWORD Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production With the Partitioning, Data Mining and Real Application Testing options SQL Given that sqlplus is a native Windows application as opposed to a Cygwin application, there is no way to do what you need directly under Mintty. The problem is that Mintty uses ptys for its console handling, but Windows applications don't know about such Cygwin constructs. All they see is a pipe, so they can't do things like disabling console echoing as they would when they have a real Windows console in which to run. The only way to make this work with sqlplus if you want to primarily use Mintty as your terminal is to spawn a cmd window for sqlplus to run in: cygstart $(which sqlplus) risin...@ctibeta2 I think that should work for you, but I haven't tested it. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Build Graphviz
On 10/12/2010 4:58 AM, Yaakov (Cygwin/X) wrote: On Tue, 2010-10-12 at 11:21 +0800, Steven Woody wrote: Thanks Jeremy. I like to try the patches. But I get the source from svn rather than the git as Yaakov suggested. Actually, I am not so well understand the page http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ports;a=tree;f=graphics/graphviz;, How should I get files from there? If I click on the file, I will be just bring into another web page with file source shown with line numbers. There is a snapshot link on each page which will give you a tarball consisting of the files in that directory. Another question is, what patches I should apply? Only the 2.26.* or the all other 2.*.* patches? Leave that to cygport. I think the problem here is that the port is configured to depend on a number of other packages so that it will be able to build various language bindings. Steven doesn't seem to need those bindings right now. I'm having trouble finding an easy way to use the port to build just graphviz itself without editing the .cygport file. Is there a way to do this? -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Build Graphviz
On 10/10/2010 10:24 AM, Steven Woody wrote: Who succeeded in building Graphviz for cygwin? Cygwin Ports has support to build version 2.26.3 from the look of things: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/graphics/graphviz/ -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Build Graphviz
On 10/10/2010 12:39 PM, Yaakov (Cygwin/X) wrote: On Sun, 2010-10-10 at 10:36 -0500, Jeremy Bopp wrote: On 10/10/2010 10:24 AM, Steven Woody wrote: Who succeeded in building Graphviz for cygwin? Cygwin Ports has support to build version 2.26.3 from the look of things: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/graphics/graphviz/ FYI, Ports SVN is obsolete; I'm now using Git: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ports;a=tree;f=graphics/graphviz I thought I remembered you mentioning something to that effect sometime in the past, but I didn't see anything about it at: http://sourceware.org/cygwinports/ Is that no longer the right place to look? YA package I should probably ITP... I would love it if that package made it into Cygwin proper because we use graphviz for a few things where I work. Right now, we have to use the Windows native build and its installer because it's easier than trying to get everyone using Cygwin Ports for just that one tool. Of course, we would also be satisfied if it was easier to use the Cygwin Ports repository with Cygwin's setup.exe. I'm well aware of the time limitations for any of this though, so I'm certainly not demanding anything. ;-) -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
