Re: how to get the windows PATH env in cygwin
2009/11/30 ︶ㄣ無名氏: > What i mean is that, how to only get the env path of windows, such as, > `C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem". As I understand it, by the time you're in a Cygwin bash shell, the environment variable has been changed by the Cygwin DLL, and the original Windows value is gone. But I believe launching a Windows process will restore it, so you can try this: cmd /c "echo %PATH%". Not at my Cygwin box to test, though. -- Mark J. Reed -- 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: UTF-related question
On Tue, Dec 15, 2009 at 1:51 PM, Eliot Moss wrote: > > Following the guidelines related to cygwin 1.7, I have > generally been using LANG=en_US.UTF-8. But I found that > if I do "man " to get a man page, and then > search (I have man's "more" program set to "less") for > a string having a dash in it, say to search for -a in the > rsync man page to find the description of that flag, it > fails to match. This is neither Cygwin- nor locale-specific. The man macro package for nroff generates actual hyphens and dashes (em and en) where appropriate. When you set LANG to C and use the text output form, all of a sudden those characters are not available, so it has no choice but to fall back to the plain ASCII '-' character. If you're looking for an en dash, you have to type an en dash. I think alt+0150 will work. If not, you'll have to figure out how to enter Unicode character U+2013. -- Mark J. Reed -- 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: bash expands $1 in strange new way
On Thu, Dec 24, 2009 at 10:19 PM, David Arnstein wrote: > I have a bash shell script named xplo that worked as desired under > cygwin 1.5. It fails under cygwin 1.7. Your shell script is incorrect, and I don't see how it worked under 1.5. This line: > set EXPLOR='/cygdrive/c/windows/explorer.exe' does NOT set a variable named EXPLOR. Instead, it sets the first positional argument ($1) to the string "EXPLOR=/cygdrive/c/windows/explorer.exe". Whatever the old value of $1 was, it's now gone. To fix, get rid of the "set". In sh and derivatives, "set" sets the positional arguments (and optionally flags that affect the shell's behavior); it does NOT set variables. Just use the assignment syntax (var=value) by itself for that. -- Mark J. Reed -- 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: cygpath and spaces in filenames when reading from a file
On Wed, Dec 30, 2009 at 7:01 AM, Corinna Vinschen wrote: > No, it doesn't. Space is used as the field separator in the file. I > assume we need an extension like allowing to specify another separator. > Another one for next year... As a first step, maybe just adding an xargs-style "--null/-0" to treat input as NUL-separated instead of whitespace-separated would be worthwhile? The options list is kinda full, single-letter-alias-wise; I see no obvious place to put a more general '--delimiter' (-d and -D and -f and -F and -s and -S are all taken). Also, allowing specification of an arbitrary delimiter would seem to open up another can of character-encoding worms. -- Mark J. Reed -- 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: cygpath and spaces in filenames when reading from a file
On Wed, Dec 30, 2009 at 1:18 PM, Christopher Faylor wrote: > That's an option that I added. I am surprised that it is space delimited > since > I thought I intended to make it newline delimited. It looks pretty intentional - it reads through the input line by line using fgets, but then calls argz_create_sep() to split each line on spaces. -- Mark J. Reed -- 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: Incorrect year in date function.
On Mon, Jan 4, 2010 at 1:40 PM, Jacob Jacobson wrote: > I am curious as to why this happened. > > I was at work yesterday and created a file. The name of the file > is created using the Cygwin date function. > > REV=$(date +rev-%b-%d-%g) > APPNAME="$1-$REV.img" %g (and the four-digit version %G) is the year according to the ISO week-number calendar; each such year is always a whole number of weeks (364 or 371 days), starting on a Monday and ending on a Sunday. Specifically, the first week is always the one containing January 4th; as such, today is 2010W1-1, the first day of the ISO year, and yesterday was 2009W53-7, the last day of the previous ISO year. So you got what you asked for, even if that wasn't what you actually wanted. :) If you want the CE year according to the standard Gregorian calendar, use %y (2-digit) or %Y (4-digit). -- Mark J. Reed -- 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: Bug printing string where the 128th char is multibyte
On Mon, Jan 4, 2010 at 5:35 PM, Eric Blake wrote: > What you've found is a bug in your own program, at lesat for the BUG.c version > of your report. The Perl and Python programs are not buggy, but they also don't exhibit the behavior for me. Although I'm still running a prerelease 1.7.0 Both also feature simpler ways to build the string, btw. Perl: my $str = '0123456789' x 13; substr($str,127,1) = 'ç'; Python: str = '0123456789' * 13 str = str[:128] + 'ç' + str[128:] -- Mark J. Reed -- 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: Bug printing string where the 128th char is multibyte
On Mon, Jan 4, 2010 at 6:24 PM, Eduardo D'Avila wrote: > I confirmed the bug on two different versions of Windows XP (Home and > Professional Editions) at my home and my workplace. I've just checked > also on a Windows Vista notebook and the bug didn't happen. What terminal are you using, what is your encoding set to, etc? I'm not able to reproduce this bug in a fresh 1.7.1 install on Windows XP Professional (32-bit). All three of your programs - C, Perl, and Python - display the full string from the beginning. I've tried creating the source with both Latin-1 and UTF-8; both work fine. -- Mark J. Reed -- 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: Bug printing string where the 128th char is multibyte
On Tue, Jan 5, 2010 at 8:15 AM, Eduardo D'Avila wrote: >> What terminal are you using, what is your encoding set to, etc? > > I'm not sure what you mean here. I run the terminal by clicking on the > Start menu shortcut "Cygwin Bash Shell" that was created by setup.exe. OK, so you're using the standard Windows command shell window. I tried both with that and with MinTTY and got the same behavior as before - no problem, entire string prints. Perhaps there's a BLODA issue? Though I didn't see anything in cygcheck.out. Are the characters are not printing at all, or are they perhaps being overwritten? Running the output through 'od' or redirecting it into a file and examining the file in a text editor might be helpful. -- Mark J. Reed -- 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*exe for legacy and current versions
On Thu, Jan 7, 2010 at 1:29 AM, Christopher Faylor wrote: > On Wed, Jan 06, 2010 at 05:00:36PM +, Andy Koppe wrote: >>It checks its own name using argv[0] and acts accordingly. > > Ooh. Prograi... SCIENCE! -- Mark J. Reed -- 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: rxvt and strange characters from man
On Thu, Jan 7, 2010 at 12:34 PM, Wayne Erfling wrote: > Turns out the solution for me was to put the commands into .bash_profile > instead of .bashrc Bash reads .bashrc in non-login shells and .bash_profile in login shells. What I do is put the stuff I want done in both cases in .bashrc and have .bash_profile source .bashrc. -- Mark J. Reed -- 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 set variables in a while loop that is passed to the rest of the script.
On Friday, January 15, 2010, Thomas Wolff wrote: > As was responded before, this isn't supposed to work in a pipe. Not in ksh > either, I think, No, it works in real ksh. If the last command in a pipeline is a builtin, it is run in the current shell. $ unset foo bar $ echo ${foo=hiya} | read bar $ echo foo=$foo bar=$bar the above will set bar but not foo in ksh. Some shells will set foo but not bar. Current bash sets neither. No shell sets both. But not Cygwin-related. -- Mark J. Reed -- 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: Japanese/Chinese language question
On Thu, Jan 21, 2010 at 8:40 AM, Corinna Vinschen wrote: > would somebody with Japanese and/or Chinese language background be so > kind to answer the below two questions? I have some (outdated) background in I18N and Japanese L10N, though I'm not a native speaker of either Japanese or any Chinese language. So I can't offer native intuition, but I can relay some technical info that might be helpful: > When comparing strings linguistically (strcoll/wcscoll), > - are Hiragana and Katakana forms of the same character to be > treated as equal or as different? (Nit: they are not "the same character" in either the technical or traditional sense of "character"; they're the same syllable, but represented by different characters.) From the Unicode point of view, they are distinct; there is no defined equivalence, either canonical or compatibility, between corresponding Katakana and Hiragana syllables. The collation algorithm (which does take linguistic context into account) doesn't seem to say anything about such comparisons, though it's possible I missed something. But as a precedent which might be helpful, I note that with linguistic sensitivity active, Oracle 10g does compare Hiragana and Katakana forms of the same syllable as equal. > - are half-width and full-width forms of the same CJK character > treated as equal or as different? According to the Unicode normalization algorithm, half -width and full-width forms normalize to the same character, so they should be treated as equivalent. From the point of view of Unicode, there is no semantic difference, and the width property is informative, not normative. It's primarily encoded in Unicode to preserve round-trip compatibility with other standards, though it's also helpful for hints to rendering algorithms. -- Mark J. Reed -- 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 -ef difference linux/cygwin (arguments)
On Wed, Apr 29, 2009 at 11:13 AM, William Sutton > Let's try this one again, and maybe we can be civil instead of > condescending and insulting? Ahh. You must be new here. :) This has come up before; an archive search might save some repetition. But if I understand the argument properly, it's a question of compatibility with scripts that expect the Cygwin ps to behave the way it does. The ps command has traditionally differed widely from implementation to implementation - the most glaring example being the BSD style options (ps auxgww) vs the SysV style (ps -elf). The modern Linux command attempts to integrate both styles, plus a third innovated by the GNU project, but the Cygwin ps command was already established as its own animal by the time that happened. (It also predates Cygwin's branding as specifically Linuxlike as opposed to generically Unixlike.) So there are configure scripts, etc. that check to see if the system is Cygwin and expect ps to behave in a certain way when it is. Making it act like Linux ps instead would break things, possibly lots of things, possibly unmaintained things. So instead, the procps(1) command is provided as an alternative for users who want a Linuxlike ps command on Cygwin. -- Mark J. Reed -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash problem
On Thu, Apr 30, 2009 at 7:27 AM, Ken Brown > A build script I was running failed because it had a command of > the form > 'eval foo=bar time '. That won't work because time is a special shell keyword, and as such only recognized when it's the first word on the command line. The same is true of all shell syntax-driving keywords such as "case", "for", "while", etc. (But not for simple built-in commands, which can appear anywhere the name of an actual command program on disk can). > I have access to a linux system in which the original command > (with > foo=bar) works. That just means that the Linux system has the standalone time(1) command installed. As it happens, my Cygwin install also has a /bin/time. You can just move the assignment to after the 'time': eval time foo=bar env | grep foo real0m0.120s user0m0.000s sys 0m0.078s foo=bar -- Mark J. Reed -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.5] v. [1.7] unison: version clash?
On Fri, May 1, 2009 at 4:44 PM, Dave Korn wrote: > I must be feeling a little "special" today. Why should there be any > relationship between 1.5 package numbers and 1.7 package numbers? I think that traditionally, if you found two Cygwin packages in the wild without any other context, and they had the same filename, they were ipso facto the same package. Unless someone messed up somewhere. Here we have two packages with the same filename that are not in fact the same package. Ergo, someone messed up somewhere. :) -- Mark J. Reed -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: WARNING: terminal is not fully functional
2009/5/6 Frédéric Bron: > WARNING: terminal is not fully functional > - (press RETURN) So you have $TERM set to something that the system doesn't recognize. What does 'echo $TERM' return in each case (rxvt-x vs rxvt-native)? --Mark J. Reed -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: WARNING: terminal is not fully functional
2009/5/6 Frédéric Bron: > rxvt-x -> TERM=rxvt-cygwin > rxvt-native -> TERM=rxvt-cygwin-native That's the problem. /etc/termcap has an entry for rxvt-cygwin-native, but not for rxvt-cygwin. What you want in that case is just TERM=rxvt. Not sure where the bug is. Either rxvt is setting TERM wrong, or you have something in your shell initialization that's overriding it, or /etc/termcap is missing an alias for the entry. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
> On May 13 02:29, IWAMURO Motonori wrote: >> Hi. >> >> I propose that the filename encoding in C locale uses UTF-8 instead of >> SO/UTF-8 What the heck is "SO/UTF-8"? -- Mark J. Reed -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
On Tue, May 12, 2009 at 3:22 PM, Corinna Vinschen > > http://cygwin.com/1.7/cygwin-ug-net/using-specialnames.html#pathnames-unusual OK, got it. So Mr. Iwamuro's proposal is that Cygwin ignore the locale setting, and just automatically convert the Windows UTF-16 filenames to UTF-8 (and back) no matter what. That seems rife with possible confusion, though. If I have my codepage set to ISO-2022 and paste in a filename, I expect it to be interpreted as ISO-2022, not as UTF-8 (which will probably fail with an invalid encoding sequence). OTOH, the SO/UTF-8 hack would seem to bode ill for the portability of, say, tar archives created under Cygwin. -- Mark J. Reed -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
On Mon, May 18, 2009 at 9:17 AM, Dave Korn wrote: > Lenik wrote: >> On 2009-5-18 14:09, Christopher Faylor wrote: >>> >>> I think the main person you should be thanking isn't a guy. >>> >> Ok. Thank you gods. >> > > Hey Corinna? Congrats! You just got a promotion! All praise to the great Corinna! -- Mark J. Reed -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Why bash failed to match this pattern?
On Fri, Jun 5, 2009 at 1:10 AM, Pan ruochen wrote: > Hi All, > > My current version of bash on cygwin failed to match this pattern: > *** > target=ar > if [[ "$target" =~ '^a' ]]; then > echo Matched > else > echo Unmatched > fi Not a Cygwin question.; that fails in any bash. The quotes suppress the special meaning of ^ and make it try to match literally. Lose them: if [[ "$target" =~ ^a ]]; then ... -- Mark J. Reed -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Re: Why bash failed to match this pattern?
On Fri, Jun 5, 2009 at 2:35 AM, Pan ruochen > But some bash does match the pattern: It's possible that the behavior has changed between bash versions, but the behavior is not Cygwin-specific. 3.2.17 on OS X also suppresses metacharacters with quotation marks, and the documentation indicates that this is the expected behavior. See http://www.gnu.org/software/bash/manual/bashref.html#Conditional-Constructs Under [[...]], third paragraph: "An additional binary operator, ‘=~’, is available [...] Any part of the pattern may be quoted to force it to be matched as a string." > $bash --version > GNU bash, version 3.2.33(1)-release (i386-redhat-linux-gnu) > Copyright (C) 2007 Free Software Foundation, Inc. > > Maybe some settings affect bash's behaviour. > > PRC > -- Mark J. Reed -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Why sh failed 'Process Substitution'?
>> Pan ruochen wrote: >>> Why sh failed to recognize Process Substitution, even if /bin/sh.exe >>> is a copy of /bin/bash.exe? It's very common in UNIXland for a program to change its behavior depending on the name by which it is invoked. ln, mv, and rm are often links to the same command; there's at least one embedded UNIXalike where all the commands in /bin are links to the same executable. The script has a #!/bin/bash at the top, indicating that it is meant to be run by bash in bash mode. If you make it executable and run it directly, that line will be honored and the shell will be invoked as bash. Or you can run it by typing "bash ./scriptname". None of this, of course, is at all Cygwin-specific. -- Mark J. Reed -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Failed Dependencies: /bin/sh needed by
On Thu, Jun 25, 2009 at 12:24 PM, Drew Holland wrote: > I am encountering a strange error when I try and install rpm's on my system > using Cgywin. Cygwin doesn't use rpm to manage its installed software; it uses setup.exe. The rpm utilities are available on Cygwin (as they are on other non-RPM-based systems: Ubuntu, Solaris, etc.), but that doesn't automatically give you an rpm database for the Cygwin installation itself that is correct and complete. If you're trying to create a package for Cygwin so your software can be installed without compilation by the end user, then it's probably a better idea to create a setup.exe-compatible one (see http://cygwin.com/setup.html for how to do that). -- Mark J. Reed -- 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 build gcc to support wchar_t and wstring on Cygwin
On Thu, Jun 25, 2009 at 1:10 PM, Match Point > wstring is not supported on my Cygwin 1.5.25. When I declare a > wstring variable my g++ 3.4.4 complains wstring is undeclared. After > reading some posted message I figured out wstring is not supported on > Cygwin 1.5 or even 1.7. To fix this I have to rebuild entire gcc. No, to fix that you have to convince the newlib developers to add wstring support to newlib. > _GLIBCXX_USE_WCHAR_T is still not defined. Cygwin does not use glibc. -- Mark J. Reed -- 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 build gcc to support wchar_t and wstring on Cygwin
On Thu, Jun 25, 2009 at 4:26 PM, Corinna Vinschen wrote: > wstring is a C++ class. It has nothing to do with libc. wstring is > supported by the G++ standard libs as soon as the underlying libc > (Cygwin/nelib) provides all necessary wide char functions to implement > that class. That should be the case for Cygwin 1.7 and gcc 4.x. Sorry, my mistake. I was thinking of the wchar_t C functions. I'll shut up now. -- Mark J. Reed -- 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: "bash: $'\r': command not found"; also "e"s nonfunctional and get deleted in bash window
On Thu, Jun 25, 2009 at 10:14 PM, Dave Korn wrote: > Richard Haney wrote: > >> I imagine that the messages involving "\r" have something to do with the >> \r\n conventions. So I should mention that I use WordPad to edit >> bash-initialization files. > > That'll be the cause of the problem then; wordpad is a windows program, so > it tends to use windows-style CR/LF line ends. You can still use it to edit > shell scripts, but always remember to run "d2u" on them afterward. Yes. I would recommend using a different editor, one that can deal with UNIX newline conventions, so you don't have to take the extra conversion step. Of course, both the Cygwin and native Windows versions of Vim, Emacs, and other cross-platform editors can do this. The better text editors for Windows can, too, but they tend to be commercial products, such as TextPad (~$30) and UltraEdit (~$50). -- Mark J. Reed -- 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: Launching CMD.EXE windows from cygwin bash
On Thu, Jun 25, 2009 at 10:19 PM, Dave Korn: >> Problem: I want to be able to launch a CMD.EXE window starting in a >> particular >> directory from my cygwin bash window. > > Just type "start" and press return. I get "bash: start: command not found." in 1.7. This works, though: cygstart /cygdrive/c/windows/system32/cmd.exe or, if you have that in your $PATH, just cygstart `which cmd` -- Mark J. Reed -- 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: Launching CMD.EXE windows from cygwin bash
I wrote: >>cygstart /cygdrive/c/windows/system32/cmd.exe >> >>or, if you have that in your $PATH, just >> >>cygstart `which cmd` As it turns out, just cygstart cmd works on both my installations at work (one 1.5 and one 1.7, both on Vista); on the PC at home (1.7 on XP) I had to specify the full path to cmd.exe. Will have to investigate that when I get home. Barry Buchbinder pointed out: > cygstart has an option to set the working directory. An excellent point! cygstart -d /path/to/directory cmd should do the trick. -- Mark J. Reed -- 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 with displaying ASCII table in mintty
On Thu, Jun 25, 2009 at 9:24 PM, Mark Harig wrote: > Is is possible to display the upper 128 entries in the ASCII > table in mintty using the 'cygutils' application 'ascii'? The ASCII table doesn't have an upper 128 entries. Only codes 0 through 127 decimal are defined by ASCII. Once you hit 128 you're not in ASCII anymore, and what you *are* in depends entirely on what code page you're using. 128 through 159 are control characters in Unicode and Latin-1, but printable characters in Windows 1252. 160 through 255 are the same in Windows 1252, Latin-1, and Unicode, but defined differently in the other ISO-8859 and ISO-2022 character sets and Windows code pages. If you're using UTF-8 (a particular way of representing Unicode characters, which are defined as numbers, as concrete bits and bytes), then only characters 0 through 127 can be expressed in one byte. Characters from 128 to 2047 take two bytes; the rest of the BMP (2048 through 65536) three bytes per character, and the rest of Unicode four bytes per character. So if you just send the byte with decimal value 128, not preceded by the start of a UTF-8 sequence, to a UTF-8 terminal, the terminal will reject it as invalid, or display gobbledygook, depending on its error handling design. -- Mark J. Reed -- 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 with displaying ASCII table in mintty
On Fri, Jun 26, 2009 at 12:51 PM, Mark Harig wrote: > Do you have any recommendations about what the utility program /usr/bin/ascii > (in the package 'cygutils') should do? Since the Cygwin version of ascii doesn't appear to have a man page, I'm not sure what it "should" do. What it appears to do is simply printout out all possible 8-bit characters so you can see what they are. Which will fail in any multibyte locale. You can write your own imitation ascii as a Perl one-liner: perl -e 'for ($i=0;$i<256;$i+=4) { for ($i..$i+3) { printf "%03d 0x%02x %c\t", ($_)x3 } print "\n"; }' which can be adjusted for different locale settings: perl -Mencoding=utf8 -e '...' adding the control-sequence support (^x) is left as an exercise for the reader. :) -- Mark J. Reed -- 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: "bash: $'\r': command not found"; also "e"s nonfunctional and get deleted in bash window
On Fri, Jun 26, 2009 at 7:46 PM, Richard Haney wrote: > Thanks all for the comments. > > It turns out that, by info discovered via using "bash --help" and then `bash > -c "help set"', I could > simply add `-o igncr' to the login command line in the cygwin.bat file. But set -o igncr only affects bash itself. That's fine for shell scripts, but you'll still have trouble with other programs and their text files (like readline and .inputrc). -- Mark J. Reed -- 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: w32api funny
On Wed, Jul 1, 2009 at 6:33 AM, Dave Korn wrote: > > I noticed this when we added StrStrI to setup.exe, and I forgot to bootstrap > the generated files; I got a bad exe that didn't work [...] So, not really funny "ha-ha", then... too bad. I was hoping for an API knee-slapper. -- Mark J. Reed -- 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: Best way to create Windows .ico file for Emacs?
On Thu, Jul 2, 2009 at 2:03 PM, Yaakov (Cygwin/X) wrote: >> Perhaps this isn't actually an XPM file? The header looks like this: >> >> /* Format_version=1, Width=64, Height=64, Depth=1, >> Valid_bits_per_item=16 >> */ >> 0x,0x,0x,0x,0x8000,0x,0x,0x0001, >> 0x8000,0x,0x007E,0x1C01,0x8000,0x,0x0006,0x1C01, >> That's a Sun ICON file. It looks like ImageMagick doesn't support that, but PBMTools does: $ icontopbm emacs.icon | convert - emacs.ico -- Mark J. Reed -- 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
Really dumb setup question.
Didn't see tihs in the FAQ: how do I install just one package? My only options at the global level are "Default", "Install", "Reinstall", and "Uninstall". I want "Skip" for everything except the one package I've selected. I don't want to upgrade anything I've already installed, or install anything that's "missing", just install the one package. Possible? -- Mark J. Reed -- 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: Why doesn't "find .|grep aword" work?
On Mon, Jul 6, 2009 at 1:13 PM, km4hr wrote: > > Do pipes work in cygwin in the usual way? Pipes on Cygwin work in the usual way. You seem to misunderstand how find and grep work. > Why doesn't the following command works on HP Unix? Why not cygwin? > I get no output from this command even though I'm sure the word "hello" is > in some files. > > find .|grep "hello" That will look for files whose *name* contains "hello". The output of 'find" is a list of filenames. You then run grep on that list looking for the string "hello". If you want to instead run grep "hello" on all the files found by find, then the simplest change to your command is to introduce the xargs ("transpose arguments") utility, like this: find . | xargs grep hello However, that will fail on files with strange names, and give you errors about trying to grep directories, so what you really want is this: find . -type f -print0 | xargs -0 grep hello None of this is Cygwin-specific. It's just the way find and grep work, on all UNIXlike systems. -- Mark J. Reed -- 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: Really dumb setup question.
On Fri, Jul 3, 2009 at 6:31 PM, Dave Korn wrote: > Yep; click on "Keep" first thing of all, that makes setup keep all your > current choices, then manually choose the new version of the particular file > you want. Should get a warning if there's any unsatisfied dependencies, > otherwise everything should "just work". Hm, I could swear I cycled around all the possible top-level choices and didn't see "Keep". Maybe because I'd already selected something? Belated thanks for the advice. In the end I just let it update everything anyway... -- Mark J. Reed -- 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: OT: gmail quoting (was Re: [OT] Re: Virus on sed.exe)
On Fri, Jul 10, 2009 at 7:11 AM, Andy Koppe wrote: >> 2009/7/10 Dave Korn <...>: > > Sorry for including your email address. > > (Does anyone know a way to switch that off in the gmail web interface?) I don't think you can customize the format of the automatic reply-quoting. But you can just delete the email address after it pops up in the composer. More annoying is the GMail mobile application, which appends the reply with quoted email addresses etc no matter what you do... -- Mark J. Reed -- 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: Username hassles
On Mon, Jul 13, 2009 at 6:07 PM, Larry Hall wrote: > If you prefer "paul" to be used, you need to do > one of two things: > > 1. Remove the "MEAD8998" user from your '/etc/passwd'. It's presumably > before the "paul" user in the file and has the same SID. > > 2. "chmod -R paul / /usr/bin /usr/lib" Correction: that should be "chown", not "chmod". > If "MEAD8998" and "paul" exist in your '/etc/passwd' file and share the > same SID, use (1). Otherwise, use (2). -- Mark J. Reed -- 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: wrong home directory
On Mon, Jul 13, 2009 at 10:58 PM, hvshare wrote: > Andy, you were right! HOME was set to the Emacs folder. I replaced it with > the directory I wanted as my Cygwin home folder and restarted my OS. Now > /home/helvio/ is my new Cygwin hom You'd be better off deleting HOME from the Windows environment list altogether. Then Cygwin will set it to whatever is in your /etc/passwd file. You should also make sure that your Windows Emacs still works. -- Mark J. Reed -- 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: Trouble creating crontab
On Thu, Jul 16, 2009 at 1:32 PM, Paul Mead wrote: > If not, how do I get it to use a different editor? I already have > EDITOR=/bin/vim in my .profile and have tried /bin/vim.exe in case that > was the problem. A couple quick things to check: 1. Make sure the EDITOR variable is exported. Just setting it locally in bash won't affect crontab. 2. Make sure VISUAL isn't set differently; it overrides EDITOR for some apps. -- Mark J. Reed -- 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: Trouble creating crontab
On Thu, Jul 16, 2009 at 1:51 PM, Paul Mead wrote: > "Mark J. Reed" <...> writes: http://www.cygwin.com/acronyms/#PCYMTNQREAIYR > So I've managed to falteringly edit my crontab using vim (doesn't feel > right and I made loads of mistakes, so I've got to find out how to get > emacs working instead) and I'm waiting to see if my test script runs at > the allotted time. Whatever setting you found and set to use vim you should be able to set to use emacs instead. Just replace 'vim' with 'emacs'. It'll be the Cygwin emacs, inside rxvt instead of in its own Window, but it'll be emacs... -- Mark J. Reed -- 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: AWK from a batch file
On Tue, Jul 28, 2009 at 12:42 PM, Matthew Swanson wrote: > I am attempting to run AWK in a bash window through a Windows batch file. I > am using: > > echo awk -v FS=',' -v OFS=',' '^{ > awk.s > echo if ^($2 ~ /^^[0-9]*$/^)>> awk.s > echo print $0 ^>^> "good_file.txt">> awk.s > echo else>> awk.s > echo print $0 ^>^> "bad_file.txt">> awk.s > echo ^}' input_file.txt>> awk.s OK, so you are creating a bash script from CMD. Invoking it outside of Cygwin means the normal bash startup files are not run, so $PATH is not set, so it can't find any commands. Replace "awk" with "/bin/awk" and you should be good, apart from the lack of execute permission. The second problem is that CMD's "echo" appends carraige returns. Add these commands to fix both that problem and the execute permission one: \cygwin\bin\d2u awk.s \cygwin\bin\chmod +x awk.s -- Mark J. Reed -- 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] bash UNC path bug?
On Thu, Jul 30, 2009 at 2:36 PM, Eric Blake wrote: >> > bash... maybe cygpath, seems to be doing something weird: > Weird - yes. But buggy - no. Backtick-quoting rules are strange. For instance, single quotes within backticks still prevent variable expansion: $ x=1 $ echo `echo '$x'` $x # not "1" So it's not as simple as backticks working like double quotes (within which single quotes have no effect whatsoever): $ echo " '$x' " '1' What's going on is that there's a rule that allows nesting backticks by using successively increasing numbers of backslashes in front of them: `outer \`inner \\\`innermost\\\` inner\` outer` and because of this, backticks essentially add yet another layer of backslash parsing and removal to the mix. This is the biggest reason to prefer new-style $(...) command substitution to backticks. None of this is Cygwin-specific, we just deal with literal backslashes more in Cygwinland thanks to DOS-style file paths. -- Mark J. Reed -- 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] bash UNC path bug?
On Tue, Jul 28, 2009 at 5:16 AM, Corinna Vinschen wrote: > Works fine in tcsh. tcsh uses the csh style of nested backticks, where the inner backticks are doubled instead of backslashed. So the backticks don't introduce any extra level of backslash parsing. Also of note when testing this sort of thing is that tcsh's echo parses backslash escapes like bash's "echo -e" does: bash$ echo '\\' \\ tcsh$ echo '\\' \ -- Mark J. Reed -- 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] bash loop and mintty hung issue
Escape in vi mode just takes you into edit mode; [ is the first character in any of a bunch of "go to the start of some group" sequences, but 2 isn't a valid continuation of any of those, so it has no effect and the 24 is entered as a repeat count. ; searches forward on the line for the last character looked for with the (f)ind command. And that's the problem - you can reproduce it by just hitting Esc and then semicolon. If you've previously entered any (f)ind command, it's fine, but if you haven't, it locks up; someone missed a degenerate case in the last readline update. On Sun, Aug 2, 2009 at 4:48 AM, Andy Koppe wrote: > 2009/8/2 ERIC HO: >> Hi Andy, FYI. I have tested out on my Linux machine running bash 3.2.48 >> (instead of 3.2.49 as on cygwin). I don't have this problem with bash >> undxterm with set -o vi and pressing shift PF key. Does this problem happen >> to you with set -o vi and pressing shift PF key when using mintty in cygwin? > > Yep, both in mintty and xterm. And actually I can reproduce it in the > Cygwin console too, by entering the offending keycode manually. After > pressing 'Escape [ 2 4', the prompt looks like this: > > (arg: 24) > > Pressing ';' at this point causes bash to hang. > > The issue only shows up on Cygwin 1.7, not 1.5. Since their bash > versions are almost identical, I'd suspect it's to do with the newer > readline on 1.7. > > Andy > > -- > 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 > > -- Mark J. Reed -- 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: !! results in -bash: syntax error near unexpected token `newline'
On Sun, Aug 2, 2009 at 9:40 PM, Robert Mark Bram wrote: > Running "!!" or "!" gives me this: > -bash: syntax error near unexpected token `newline' > > Any ideas what I can do about it? For starters, read http://cygwin.com/problems.html and follow the advice there; we need more information to help resolve this. I'm assuming that the previous command you're trying to repeat worked the first time with no such syntax error... I can't reproduce this problem on my system (1.7/XP SP3). -- Mark J. Reed -- 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: $DISPLAY variable empty after SSHing
X11 forwarding has to be enabled on the server. If it's not, then any request by the client to forward X connections (due to -X or -Y options or ForwardX11 in ~/.ssh/config or /etc/ssh_config or wherever) will be ignored. Check the sshd_config on the final host (the "work computer"). -- 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 diff: /bin/ksh.exe
On Tue, Aug 4, 2009 at 4:08 PM, Paul McFerrin wrote: > Just want to point out a slightly difference in behavior of ksh > @(#)PD KSH v5.2.14 99/07/13.2 OK, please don't assume that (1) what you're seeing is happening for everyone, or (2) it was intentional ("you are forcing me *A LOT* of extra typing."). Getting accusatory does no-one any good. Please also follow the guidelines for problem reports at http://cygwin.com/problems.html. Same pdksh version on 1.7 has no issues with multiple wildcards for me, so something else is going on: $ cd /cyg*/c/Doc*/mjreed/App*/Moz*/Fire*/Pro*/*default $ pwd /cygdrive/c/Documents and Settings/mjreed/Application Data/Mozilla/Firefox/Profiles/c52muy7a.default (Note that I had to use /cygdrive/c in place of /c, though. Do you have a symlink or extra mount point?) -- Mark J. Reed -- 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 diff: /bin/ksh.exe
On Wed, Aug 5, 2009 at 6:18 AM, Dave Korn wrote: > Paul McFerrin wrote: >> I believe this is a non-problem. > This is a 1.7-vs-1.5 difference in the underlying Cygwin DLL then, and not > related to ksh; yes? What part of "non-problem" do you not understand, Dave? ;) Seriously, is it a difference at all? I thought wildcard matches were always case-sensitive in 1.5 too. -- Mark J. Reed -- 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 backslash variable - stores dos based filename with path
On Wed, Aug 5, 2009 at 4:13 PM, Rajesh George wrote: > "e:\test\testcomn\util\jre\1.1.8\bin\jre.exe" become > "e:testtestcomnutiljre1.1.8binjre.exe" and I got "command not found" error. > In this case, am not allowed to edit the any bat/sh files. But I can modify > the CygWin settings. Well, we'd need to see the bat file to be sure, but chances are you're out of luck. I'm guessing it's doing something like bash -c "somecommand c:\some\path\here" then there's nothing you can do - by the time somecommand sees the pathname, the backslashes are gone. and there's no way it can figure out where they went. You don't have to change them to forward slashes, you just need to quote them: bash -c "somecommand 'c:\some\path\here'" But if you can't change the batch file, then I can't think of any workarounds. Maybe someone else can... but I don't know why you'd have batch files calling Cygwin commands that can't be modified to use Cygwin conventions. -- Mark J. Reed -- 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.0: getnameinfo bug
On Thu, Aug 6, 2009 at 8:48 AM, Zhiming Zhou wrote: > This bug happens on every 1.7.0 beta version. > I use getnameinfo function with NI_NUMERICHOST flag, I assume that it works if you pass NI_NUMERICSERV (returning e.g. "21" instead of "ftp" in that case). According to the RFC (2553), the specific behavior here is not defined: If the flag bit NI_NUMERICHOST is set, or if the host's name cannot be located in the DNS, the numeric form of the host's address is returned instead of its name (e.g., by calling inet_ntop() instead of getipnodebyaddr()). If the flag bit NI_NAMEREQD is set, an error is returned if the host's name cannot be located in the DNS. If the flag bit NI_NUMERICSERV is set, the numeric form of the service address is returned (e.g., its port number) instead of its name. The two NI_NUMERICxxx flags are required to support the "-n" flag that many commands provide. The Linux version of the function treats services and hosts alike in this regard, but the critical bit of the spec ("or if the host's name cannot be located in the DNS") does not have a parallel in the description of the behavior with regard to services. This difference is reinforced by the fact that NI_NAMEREQD is only stated to affect hostname resolution, and there's no corresponding "service name required" flag. So it appears that the Cygwin behavior is POSIXly correct, but perhaps behaving more like Linux in this regard is desirable. -- Mark J. Reed -- 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.0: getnameinfo bug
On Thu, Aug 6, 2009 at 9:12 AM, Corinna Vinschen wrote: > On Aug 6 09:01, Mark J. Reed wrote: >> According to the RFC (2553), the specific behavior here is not defined: > Microsoft's getnameinfo man page conveniently notes that this is the desired > behaviour according to section 6.2 of RFC 3493. Whups! I was looking at an obsolete RFC. My mistake. Sure enough, 3493 says If the service's name cannot be located, the numeric form of the service address (for example, its port number) shall be returned instead of its name. I'll go back to lurking now. -- Mark J. Reed -- 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 jobs visible
n Mon, Aug 10, 2009 at 8:15 AM, Thorsten Kampe wrote: >> > I upgraded to Windows 7 ... > I'll probably wait until 1.7 is out of beta and an "official" migration > document is > released. OK, but why are you willing to upgrade to Windows 7 while *it's* still in beta but reluctant to upgrade to the beta version of Cygwin that's supported on it? That seems a bit odd. -- Mark J. Reed -- 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 jobs visible
On Mon, Aug 10, 2009 at 9:29 AM, Thorsten Kampe wrote: > Only if you assume that Windows 7 is still in beta (which it is not). It won't be released until October. The current version is a "release candidate". How is that different from being in beta? Regardless of terminology, both Windows 7 and Cygwin 1.7 are stable but as yet unreleased pieces of software. -- Mark J. Reed -- 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 jobs visible
On Mon, Aug 10, 2009 at 10:28 AM, Thorsten Kampe wrote: > The current version is "RTM" - "Released to manufacturing" since last > Thursday. Ah, missed that milestone. I retract the observation then. -- Mark J. Reed -- 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 jobs visible
On Mon, Aug 10, 2009 at 5:17 PM, Christopher Faylor wrote: > Actually, I meant Cgywin 1.7. Sorry for the cornfusion. cgf apologizes! In writing! Alert the media! :) -- Mark J. Reed -- 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: Supporting Data Types "ushort_t" and "uchar_t"
On Wed, Aug 12, 2009 at 10:19 AM, Larry Adams wrote: > It's Solaris 10 :(. They must "set" the standard these days ;) Hm. How did Solaris 10 typedefs show up? Does the app in question not compile out of the box on Linux, either? -- Mark J. Reed -- 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: Supporting Data Types "ushort_t" and "uchar_t"
On Wed, Aug 12, 2009 at 10:46 AM, Larry Adams wrote: > My concern is that the "*_t" typedefs are supposed to be hardware architecture > agnostic, and there must have been some reason, other than "geeze everything > else is that way, so why not do those two" to have done this for Solaris. An understandable concern, though I'm having trouble imagining any scenario where a sensible definition of "ushort_t" and "uchar_t" would be anything other than "unsigned short" and "unsigned char". -- Mark J. Reed -- 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 the titlebar
Putting title-setting escape sequences in PS1 has the unfortunate side effect that the shell thinks that it has output those characters, and shrinks the length of the line readline has to work with by that amount. A better option is to define PROMPT_COMMAND to echo the appropriate sequence. -- Mark J. Reed -- 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 the titlebar
On Wed, Aug 12, 2009 at 12:30 PM, Andrew DeFaria wrote: > It was my understanding that one of those escape sequences told the shell > not to count these characters. Ah, you're right! Things between \[...\] in the prompt string aren't counted. I missed that little detail. I retract my objection. > What's PROMPT_COMMAND? bashism. A string of shell commands that gets run immediately before every prompt is displayed. -- Mark J. Reed -- 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 the titlebar [OT]
On Wed, Aug 12, 2009 at 12:57 PM, Jason Pyeron wrote: > http://www.googleit1st.com/search?hl=en&safe=off&q=ssh+host+titlebar&aq=f&oq=&aqi= For this sort of thing, I prefer lmgtfy: http://lmgtfy.com/?q=ssh+host+title+bar -- Mark J. Reed -- 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 the titlebar [OT]
On Thu, Aug 13, 2009 at 12:29 AM, Andrew DeFaria wrote: > Mark J. Reed wrote: Hey, I was just recommending lmgtfy. I wasn't endorsing Jason's reply. You'll note I replied elsewhere with arguably useful information... :) -- Mark J. Reed -- 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: No etc/passwd (was) Re: (everything!) command not found
On Sun, Aug 16, 2009 at 11:30 AM, DY wrote: > In case anyone else ever needs this, if you install cygwin, then get command > not found for everything, you need to:[set CYGWIN_HOME and add > %CYGWIN_HOME%\bin to PATH]. That's quite strange; neither of those should be necessary. I have no CYGWIN_HOME set, and my Cygwin bin dir is not in my Windows PATH. (The latter is handy if you want to run Cygwin commands from the Windows shell, of course). How are you starting Cygwin? The normal shortcut runs C:\Cygwin\Cygwin.bat, which looks like this on my install: @echo off C: chdir C:\cygwin\bin bash --login -i -- Mark J. Reed -- 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: No etc/passwd (was) Re: (everything!) command not found
No /etc/passwd file at all? You're looking from bash, not from Windows, right? From Windows it'd be C:\Cygwin\etc\passwd... This sounds like something went wrong during the installation. You can generate the default passwd file like so: mkpasswd -l >/etc/passwd But if your prompt is "c:\cygwin" then that sounds like you're not in bash at all, but still in the Windows shell (cmd.exe or command.com). On Sun, Aug 16, 2009 at 11:44 AM, DY wrote: > Or maybe the problem is the profile. OK, totally different. The password file identifies the users who exist on the system and the location of their home directory. The profile is a set of bash commands to run automatically when you log in. The only connection is that your home directory is used to find your personal profile files. > After a bit of searching, I found the profile in /etc/defaults/etc, > but I don't know how to edit it properly to make the above happen. /etc/defaults/etc/profile is not used by anything; that's just a copy of the default file that goes into /etc/profile. What actually gets run is /etc/profile. But the way to set things up for your account is to make a .profile (or .bash_profile, if you'll always be using bash) in your home directory. To set the prompt you need to set the PS1 variable. But again, make sure you're actually running bash! -- Mark J. Reed -- 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: No etc/passwd (was) Re: (everything!) command not found
On Sun, Aug 16, 2009 at 12:56 PM, DY wrote: > I basically went to the cygwin page, picked "install now", downloaded > setup.exe, right-clicked on it and chose "run as administrator", then ran it, > picked to > install perl, python, devel, the vim editor, and x11, and then let'er rip. ... along with all the packages that are there by default, right? :) > I'm definitely in cygwin. My prompt is bash-3.2$ Uhm, I thought you just said your prompt was "c:/cygwin" ? -- Mark J. Reed -- 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: No etc/passwd (was) Re: (everything!) command not found
On Sun, Aug 16, 2009 at 1:07 PM, DY wrote: > no - when I was looking at the cygwin icon I was saying the path. > Sorry for the confusion. "Here's the deal. My prompt defaults to c:/cygwin and I want it to default to my home directory (with the path as the prompt)." Confusing indeed! So what are you actually trying to accomplish now? -- Mark J. Reed -- 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: Re: Changing HOME for PERL
On Thu, Aug 27, 2009 at 11:24 AM, Dexter Michael wrote: > $ echo $PATH [...] Holy giant PATH, Batman! That's like 1800 characters long! Not that that's necessarily a problem on its own... I'm curious about this bit: ...:"C:/Program Files/Common Files/EMC":... Does quoting the Windows-style pathname actually work? That seems suspicious. -- Mark J. Reed -- 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: Cannot get 'Hello World' to compile
You named your program with a .c and ran gcc on it. Both of those mean C, which is a different language from C++. A C++ compiler will compile a C program, but not the other way around. Rename your file to end in .cc, .c++, .cpp, or .cxx, your choice (or capital .C if you have case sensitivity turned on), and run "g++" instead of "gcc". -- Mark J. Reed -- 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: Cannot get 'Hello World' to compile
On Fri, Aug 28, 2009 at 8:51 AM, ken j wrote: > That was it - using g++ as the compiler and changing the file name to .cpp > The executable file was placed in my cygwin/home/username folder. Do I have > to specify that folder in the set path variable for Cygwin to see it? I'm > not entirely clear on this issue. You can always specify the path to an executable, in which case its directory doesn't have to be in your $PATH. If you've just compiled it, it's probably in the same directory you're in, and you can just do ./name to run it. If what you've created is a useful program that you want to keep around and be able to run as a command without specifying the path every time, then the thing to do is move it into a directory that's in your $PATH. Many people have a "bin" directory in their home directory for adding their own commands to the system, and put "$HOME/bin" in the front of their $PATH. -- Mark J. Reed -- 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: Cannot get 'Hello World' to compile
On Fri, Aug 28, 2009 at 10:34 AM, ken j wrote: >BTW I've found that I do NOT need to type './' but > rather only '/' to get an exe file to run in Cygwin. That's only true if the executable is in the root directory (c:\cygwin in Windows, / in Cygwin). > Also, all of my compiled executables go to c:\cygwin\home\username, not the > directory I'm in, which is c:\cygwin. That makes no sense. g++ -o file will put the executable in that file in the current directory. If it's going elsewhere, then you're telling it to put it elsewhere. 1) Why do you keep reporting Windows paths when talking about Cygwin? You're running these commands inside a Cygwin bash window, right? 2) what does the command 'pwd' tell you? -- Mark J. Reed -- 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: Changing HOME for PERL
On Thu, Aug 27, 2009 at 10:05 PM, Larry Hall (Cygwin) wrote: > Have we arrived at the end of the thread yet? You know who else liked Usenet better than mailing lists? HITLER! There. Thread over. :) -- Mark J. Reed -- 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: GNU screen hangs
Andrew DeFaria wrote: > Excuse me, I'm off to the tongue tanning salon... ;-) Crazy Americans! Tanning one end while bleaching the other! What's going on in this country?! -- Mark J. Reed -- 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: Set root shell prompt in /etc/profile ?
On Fri, Sep 4, 2009 at 6:50 PM, Eric Blake wrote: > The ideal way would be patching bash to recognize if the current user has > root privileges (rather than its current check for just uid==0), so that > the PS1 escape \$ automatically printed # for privileged and $ for normal. > > I'll add it to my TODO list, but if someone comes up with a patch first, > I'd gladly review it. Got a pointer to latest bash sources? I tried the savannah cvs repository and they don't seem to be there anymore. -- Mark J. Reed -- 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: Set root shell prompt in /etc/profile ?
Well, based on the 4.0 sources, there are only a couple places where it checks for euid==0, but using a cached value rather than calling geteuid() every time. So I'm looking to see what the cascade effect would be of just storing a 0 there when running on Cygwin and the user is in the Administrators group. If that's too disruptive I'll look at adding a flag to the same structure, setting it appropriately, and testing it instead of the euid. On 9/5/09, Larry Hall (Cygwin) wrote: > On 09/04/2009 08:14 PM, Mark J. Reed wrote: >> On Fri, Sep 4, 2009 at 6:50 PM, Eric Blake wrote: >>> The ideal way would be patching bash to recognize if the current user has >>> root privileges (rather than its current check for just uid==0), so that >>> the PS1 escape \$ automatically printed # for privileged and $ for >>> normal. >>> >>> I'll add it to my TODO list, but if someone comes up with a patch first, >>> I'd gladly review it. >> >> Got a pointer to latest bash sources? I tried the savannah cvs >> repository and they don't seem to be there anymore. > > You could always use what's available through 'setup.exe'. > > -- > Larry Hall http://www.rfk.com > RFK Partners, Inc. (508) 893-9779 - RFK Office > 216 Dalton Rd. (508) 893-9889 - FAX > Holliston, MA 01746 > > _ > > A: Yes. > > Q: Are you sure? > >> A: Because it reverses the logical flow of conversation. > >>> Q: Why is top posting annoying in email? > > -- > 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 > > -- Sent from my mobile device Mark J. Reed -- 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: Set root shell prompt in /etc/profile ?
Ack. Apologies for the email-addressful TOFU. I unthinkingly replied using the Gmail Mobile app, which invisibly, uneditably, and unavoidably appends the original text below the message. I've switched to the browser for this msg. Mea maxima culpa. -- Mark J. Reed -- 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: syntax for Cygwin bash invoking Win apps
On Wed, Sep 9, 2009 at 11:27 AM, Ziser, Jesse wrote: >>> $ cmd /c echo "\"abc\"" >>> "\"abc\"" >>> >>> # Wahhh?! >>> >>> Anyone who knows the explanation would make me very grateful. I've tried >>> this with other Windows apps too, and the same weirdness seems to occur. Larry Hall: >>All of the above is consistent with bash shell quoting. No, it's really not. Those backslashes should be long gone by the time cmd.exe gets its arguments, yet it echoes them. It seems that the Cygwin version of bash stops short before doing some of the work it normally does itself on other systems, assuming the executed command will have its command line run through the preprocessor in the Cygwin DLL. -- Mark J. Reed -- 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: syntax for Cygwin bash invoking Win apps
On Wed, Sep 9, 2009 at 12:05 PM, Christopher Faylor wrote: >>>>> $ cmd /c echo "\"abc\"" >>>>> "\"abc\"" >>>>> >>>>> # Wahhh?! >>>>> >>>>> Anyone who knows the explanation would make me very grateful. I've tried >>>>> this with other Windows apps too, and the same weirdness seems to occur. >> >>Larry Hall: >>>>All of the above is consistent with bash shell quoting. >> >>No, it's really not. Those backslashes should be long gone by the >>time cmd.exe gets its arguments, yet it echoes them. It seems that >>the Cygwin version of bash stops short before doing some of the work >>it normally does itself on other systems, assuming the executed >>command will have its command line run through the preprocessor in the >>Cygwin DLL. > > Actually, I'd say that was cmd doing something funky. It's hard to believe > that bash was actually special-casing cmd.exe. I don't think it's special-casing cmd.exe. I think some of the command line processing that is done by bash on Linux has been moved out of bash and into the DLL command line preprocessor on Cygwin. But even if I'm wrong about the details, bash has to be doing something different here. On any other UNIX system, the "cmd" command would get an argv of ["cmd", "/c", "echo", "\"abc\""], but here it seems to be getting ["cmd", "/c", "echo", "\\\"abc\\\""]. -- Mark J. Reed -- 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 bash in rxvt with both login shell and in a specific directory?
When invoked as a login shell, bash changes to your home directory, so the fact that it was started in the target directory becomes moot. I would advise adding something to your .bash_profile or .bashrc that looks for an environment variable containing a directory and cd's there if it's set. if [ -n "$STARTDIR" ]; then cd "$STARTDIR" fi Then you have to set that somehow. This is somewhat roundabout but effective: C:\cygwin\bin\rxvt.exe -cd "path" -e /usr/bin/bash -c "STARTDIR=\"$PWD\" exec /bin/bash --login" On Wed, Sep 9, 2009 at 1:09 PM, KARR, DAVID (ATTCINW) wrote: > I'd like to have a command line that will run bash inside rxvt, both as > a login shell (so I get all my paths and profile) and in a specific > directory. I know how to get it to a specific directory, and I know how > to make it a login shell, but I can't figure out how to get both. > > If I use this: > > C:\cygwin\bin\rxvt.exe -ls -cd "path" -e /usr/bin/bash -l > > I get a login shell, but at my home dir, not at the specified path. > > If I remove the last "-l", it goes to the correct directory, but it > didn't appear to load my profile (PATH isn't correct, for instance). > > -- > 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 > > -- Mark J. Reed -- 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 bash in rxvt with both login shell and in a specific directory?
On Wed, Sep 9, 2009 at 1:31 PM, Gary Johnson wrote: > C:\cygwin\bin\rxvt.exe -e /bin/bash --login -c "cd /usr/local/src; exec > bash -i" A good solution, but it won't work if you do anything in .bash_profile that's not inherited by child shell processes (aliases, shell functions, etc), since .bash_profile won't be executed by the bash -i. Of course, it's not good practice to do such things in .bash_profile; better to put them in .bashrc (and have .bash_profile source .bashrc so they happen in login shells, too)... but something to watch out for. -- Mark J. Reed -- 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: syntax for Cygwin bash invoking Win apps
On Wed, Sep 9, 2009 at 2:20 PM, Ziser, Jesse wrote: > --- On Wed, 9/9/09, Christopher Faylor [...] wrote: >From: [...] Please don't quote email addresses and message headers. > OK, yeah, I now see that is basically what's going on. > Bash is processing it as normal and then Cygwin is adding all kinds of > quoting > before invoking the Windows executable. Makes sense. Bash is stripping the backslashes, but then Cygwin is putting them back. So their apparent invulnerability is an illusion. > However, it does more than quote them (which would only bother me a little), > because it also added backslashes in front of the quote-marks That is "quoting". In this context, "quoting" means "marking special characters so that they are not interpreted according to their special meaning", a.k.a. "escaping", and is not limited to quotation marks. -- Mark J. Reed -- 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: Reading what should not!
On Mon, Sep 14, 2009 at 4:29 AM, Angelo Graziosi wrote: > I do not know how Fedora works, but on Kubuntu the user created when > installing the SO is also 'root': one need only to use 'sudo...'. After > typing the password it 'remains active' for about 15 minute. That makes no sense. "sudo" means "run as root". If you're already root, there's no need for sudo, and most systems don't even allow root to run the sudo command. In traditional UNIX, either you're root, in which case you have the full run of the box with no need to ask for extra permissions, or you're not. Secured OSes like SELinux change those rules, but you're no longer in the realm of general Linux at that point. It sounds to me like your Fedora created a user named "root" who is not really "root" (uid 0). Which might be a security thing, but is sure to lead to confusion. What does 'id' report? -- Mark J. Reed -- 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: Reading what should not!
On Mon, Sep 14, 2009 at 10:26 AM, Angelo Graziosi wrote: > I do not have Fedora but Kubuntu (8.04 and 9.04). On Kubuntu the user > created in the installation step, say 'pippo', is also 'root' in the sense > that 'pippo' needs 'sudo' (or 'sudo su') for administrative usage. OK, then, big difference. 'pippo' is not root, pippo is able to do things as root when needed. Administrative users on Windows are treated as equivalent to root by Cygwin. If you're saying that admin users should have to use sudo or equivalent to gain elevated access in Cygwin, then that's a feature request. Does it match what Windows does? Outside of UAC in Vista I'm unaware of Administrators having to do anything to activate their privileges. -- Mark J. Reed -- 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: Strange tar error with --format=ustar: value 4294967295 out of gid_t range 0..2097151
On Tue, Sep 15, 2009 at 5:34 PM, Judy Anderson wrote: > Emacs is not bothering its little head about cygwin, though; I'm launching it > outside > the cygwin environment. Then that's a completely separate emacs installation. You should be able to run the Cygwin one by just creating a shortcut to c:\cygwin\bin\emacs-nox.exe or c:\cygwin\bin\emacs-x11.exe... -- Mark J. Reed -- 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: goldstar? Re: cygdrive prefix
On Wed, Sep 16, 2009 at 9:44 PM, Christopher Faylor wrote: [re: Shaddy Baddah] > Wow. Nice summation of the reasons for the need for a c:\cygwin. > > Can I get a goldstar here? Indeed, a nice summary. Let me dispel some misconceptions that piped up in the Apple comparison: the two ways of thinking may live side by side in OS X, and they coexist peacefully (some would say beautifully), but they aren't really integrated in the sense being described here. Mac-ish apps live in /Applications; UNIX-ish apps live in /bin (or /usr/local/bin, or /opt/local/bin if you use MacPorts, or /sw/bin if you use Fink, or...). Mac apps come as disk images (.dmg)'s usually containing packages (.mpkg); UNIX apps are either manually installed, or managed via port or fink (the latter of which uses apt behind the scenes). There's no grand unified packaging system. In fact, if someone wants access to all the goodies that are easily installable via MacPorts and Fink, then there's a good chance they have two or three installations of some shared libraries: one for the main OS and one for each of the packaging systems. If there's a Mac app to launch a UNIX program (e.g. Gimp.app), chances are the UNIX binary it uses is completely separate copy that lives in the app's folder in /Applications, even if there's a perfectly good copy in a system bin directory. If you navigate using the Finder (OS X equivalent of Windows Explorer), the system directories like /bin and /etc don't even show up. Really, the two modes of operation don't talk to each other much. They just share a filesystem. It works because they mostly leave each other alone. There's no tradition in Mac land of creating a top-level "bin" folder and putting things in there, because there was no command line at all on the traditional Mac OS, so there was no point. Which means the sort of conflicts mentioned by Shaddy rarely arise. -- Mark J. Reed -- 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: The C locale
On Tue, Sep 22, 2009 at 12:26 PM, Lapo Luchini wrote: > There never was any ISO-8859-1 "Ť" in the first place, only one > a-umlaut entered in WindowsExplorer (in the expected way) and correctly > interpreted by a UTF8-capable terminal which is doing his job. > > Nobody ever intended to write a Latin1 string with the meaning of > "A-ring + currency symbol" which has been translated by chance in a > a-umlaut... Yes, but it's working because you (1) lied about your locale (using C when your terminal is set to UTF-8) and (2) happen to have your terminal set to UTF-8, which is how Cygwin happens to be encoding the character. It's a big accident and stops working if you were actually using a non-UTF-8 terminal and locale (hopefully matching ones). -- Mark J. Reed -- 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: The C locale
If I switch the console font to Lucida, I can see the Euro sign, too (even on XP Pro). But mixing and matching with Cygwin doesn't work well H:\>echo € | c:\cygwin\bin\od -t x1 000 3f 20 0d 0a (the Cygwin process saw the Euro sign as a question mark) but H:\>c:\cygwin\bin\echo € | c:\cygwin\bin\od -t x1 000 e2 82 ac 0a which is the proper UTF-8 encoding of the Euro sign. So the output of a Windows process coming in through a pipe is treated differently than input from the Windows console. -- 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: sftp on a Windows 2003 server
On Thu, Sep 24, 2009 at 12:27 PM, Dave M wrote: > *** Warning: The permissions on the directory /var are not correct. > *** Warning: They must match the regexp d..x..x..[xt] > *** ERROR: Problem with /var directory. Exiting. > > t...@s-exsyslog01 ~ > $ ls -l /var That shows the permissions on the files *inside* of /var, not /var itself. Add the -d option to ls (ls -ld /var) to see the permissions on /var itself. But chances are it's like /var/cache, /var/lib, /var/run, and /var/tmp in your output, which have no "other" access at all, when they need at least execute. /var/empty, which you mentioned, already has the right permissions, as does /var/log. Very odd. -- Mark J. Reed -- 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
[1.7] Setup won't create local package directory?
On "Cygwin Setup - Select Local Package Directory", it says "The directory will be created if it does not already exist." But if I type in the name of a new folder (whose parent folder exists), and I get this error message: Could not change dir to [...full path...]: The system cannot find the file specified. [0002] [Abort][Retry][Ignore] Anyone else seeing this? This is on a fresh Windows XP Pro install. -- Mark J. Reed -- 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 rm file, but no error message
On Mon, Oct 5, 2009 at 7:16 AM, Ronald wrote: > Why don't I get an error message here? > > $ ls -l test.zip > -rwx--+ 1 Administrators 1153454 Oct 5 12:49 test.zip > $ rm test.zip > $ echo $? > 0 > $ ls -l test.zip > -rwx--+ 1 Administrators 1153454 Oct 5 12:49 test.zip > > Obviously the file wasn't removed, but rm does not give any error message. > Any idea why? Obligatory dumb question: you don't happen to have 'rm' aliased to 'rm -f', do you? What filesystem? -- Mark J. Reed -- 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 setup.exe flagged by AVG as high level security threat because of Win32.AirCrack.c
On Wed, Oct 7, 2009 at 8:30 AM, Martin N Brampton wrote: > I cannot find any reference to AirCrack anywhere in documentation directly > related to Cygwin. Unless you got a bad copy of cygwin from a disreputable site, that someone has inserted a virus into, it doesn't contain aircrack or any other malware. It is most likely just a false positive match from the virus checker, which is not an uncommon occurrence. See http://cygwin.com/faq/faq-nochunks.html#faq.setup.virus. -- Mark J. Reed -- 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.5, 1.7: Bash regex not recognizing word boundaries
On Mon, Oct 19, 2009 at 4:50 PM, Allen Halsey wrote: These should print "Matched", but they don't: $ REGEX='\bcat\b' $ [[ "dog cat bird" =~ $REGEX ]] && echo "Matched" $ REGEX='\' $ [[ "dog cat bird" =~ $REGEX ]] && echo "Matched" It's worth noting that this is not limited to Cygwin; I'm seeing the same behavior on OS X (with the same version of bash as my Linux system where the above works as intended). I suspect it's a factor of the regex library used to build bash rather than bash itself. -- 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: Re: gawk Has Problem With CRLF in Mixed Binary/Text Files
On Thu, Oct 22, 2009 at 9:43 PM, P.A.Long wrote: Please don't send cygcheck output inline. Now any search for any of the words that happened to show up in that output will find your message... -- Mark J. Reed -- 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: bash 3.2.49(23): when I start a bash window, $HOME is the DOS value rather than /home/lwv27
On Fri, Oct 23, 2009 at 12:55 PM, Larry W. Virden wrote: > $ echo $HOME > /cygdrive/c/Documents and Settings/lwv27 That looks like it's inherited from Windows. Cygwin won't set HOME if it's already set in the Windows environment. > Neither of these directories under /home are associated with me. They > are, however, associated with the person who is running setup Ah. IIRC, if you're logging into Cygwin as a user other than the one who set it up, you'll have to use mkpasswd to add that user to the Cygwin environment. -- Mark J. Reed -- 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 increase the memory available to diff in cygwin 1.7?
On Monday, October 26, 2009, Kenneth Chiu wrote: > cmp doesn't recurse, though, at least as far as I can tell. > In theory, I could use find, then cmp, plus some scripting, > but seems simpler to just write a small C program > to do it. Well, as a start, you could try this: find "$src" -type f -print | while read f; do cmp "$f" "${f/$src/$dest}" ; done The concatenation of its stdout and stderr will include distinguishable lines enumerating the following sets: all files in "$dest" that differ from the corresponding file in "$src" all directories in "$dest" that correspond to files in "$src" and vice-versa all pathnames under "$dest" that don't exist despite there being a corresponding file under "$src" Which seems to be all the information you were looking for. You can then postprocess the output to format it however you like. Nothing there screams C to me. Perl, maybe... -- 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: ash "gotcha", other 1.7 upgrade wrinles
On Mon, Oct 26, 2009 at 5:26 PM, Larry Hall (Cygwin) wrote: > It is not gratuitous. 'ash' is now 'dash' instead of 'bash'. Dash is a > more standards compliant shell which is also faster. Huh? ash was never bash, and ash.exe was part of the dash package last I checked, so I'm confused by the above statement. Ash is the Almquist Shell, and Bash is the Bourne-Again Shell. Ash is designed to be lightweight and fast while (mostly) achieving POSIX compliance, while Bash is designed to be feature-rich and as POSIX-compliant as you want (plus some compliance with non-POSIX features of the Korn Shell thrown in for good measure, along with lots of purely idiosyncratic Bashisms). Both are inspired by the original UNIX Bourne shell, but as far as I can tell they have no actual code in common with it or each other. Dash (the Debian Almquist Shell) is the port of ash to Linux, which has since had further development... -- Mark J. Reed -- 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: Bash - IF Statement
You're still sending TOFU. Please stop. On Tue, Oct 27, 2009 at 5:54 PM, briglass111 wrote: > It didn't matter if I believed what I read on the internet or not, I couldn't > get the IF-statement to work, and when I queried a unix user, he wasn't sure Sounds like you need to associate with a better class of UNIX users. :) The point is, bash scripting syntax is not a Cygwin-specific issue, and it would in fact be very hard for Cygwin to screw that up. It's always a good idea to try something on Linux first and see if it really behaves any differently there before complaining that it's broken on Cygwin. -- Mark J. Reed -- 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: Limit for bash variable ?
On Mon, Nov 2, 2009 at 4:51 PM, cuicui wrote: > Hello, > > I need to store some long strings in a bash variable, I'd like to know if > there's a limit in length (last version of bash/cygwin 1.5). > > At the moment the string is 3.185 chars long. It's a temporary situation > until I figure something better out. There is no limit in bash or Cygwin, as far as I know (just successfully tested up to 13,598,720 bytes in 1.7). However, if you export the variable to the environment and expect it to be visible to a Windows program using GetEnvironmentVariable(), then there is (or at least used to be) a hard length limit of 32,766 characters (32,767 including the trailing NUL). -- 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: missing 'rand' command
On Sat, Nov 7, 2009 at 12:27 AM, Lee D. Rothstein wrote: > My bad. Thanks. Sorry. How silly of me to expect a rand(1) page to be for a > rand command. This is something of a quirk of the openssl doc, useful because you can in fact set up the openssl subcommands as standalone UNIX shell commands - e.g. "ln /usr/bin/openssl /usr/bin/rand" will create a "rand" exectuable that behaves just like "openssl rand". There's probably a 'make install' option in the openssl distro that does this for all or some subset of the subcommands. Anyway, this sort of man page quirk is not limited to openssl; it's always a good idea to check the SYNOPSIS to see if the man page foo(X) is actually for a command/function named "foo" or if there's something else going on. -- Mark J. Reed -- 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