Re: RFD: cygwin + *native* MinGW compiler
At: http://www.cygwin.com/ml/cygwin/2009-01/msg00848.html Charles Wilson said: Greg said >> >>I use '--build=i686-pc-mingw32 --host=i686-pc-mingw32'. Here: >> http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00193.html >>you say that's lying to 'configure', but you also observe that >>I'm in excellent company. I'd be dismayed if that broke. > >Well, as I point out above: it's already very fragile, and.requires a >great deal of careful setup to get it to work "correctly" (if generating >DLLs with the wrong name can be considered "correct"). > >I wouldn't want to gratuitously break this usage, but I am leaning >towards endorsing the suggestion that it's bad to lie to your toolchain. >However, if you REALLY want to do so, and assume all the risk of >breakage/failure/hairloss/heartburn, then...set these [*] environment >variables before you ./configure, and then cross your fingers... The reasons I use "--build=mingw32 --host=mingw32 --target=mingw32" when building gcc are 1) I have, perhaps mistakenly, assumed that "--build=" referred to the OS of the compiler, not the ethnicity of the shell. 2) my build gcc is a mingw32 gcc, and unlike a cygwin-hosted gcc, doesn't understand symlinks. "--build=cygwin32" would suggest that the native gcc understands symlinks. Ditto for my binutil and gdb apps which do not depend on cygwin. 3) specifying "--host=mingw32 --target=mingw32" usually works just fine too (within a cygwin bash shell), for most projects, as long as there are no assumptions about symlinks. 4) "--build=mingw32 --host=mingw32 --target=mingw32" always seemed to be a natural way to do a bootstrap. I don't set any special environment variables before I "bash ./config.sh" from a DOS prompt (my everday path just put C:/mingw/bin in front of C:/cygwin/bin) and I don't cross my fingers because I know it has worked for 10 years or so. Danny -- 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: Finding out login history
Marco Atzeri yahoo.it> writes: > RTFM > > man last > touch /var/log/wtmp uh - thanks! Ronald -- 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: RFD: cygwin + *native* MinGW compiler
Danny Smith wrote: > The reasons I use "--build=mingw32 --host=mingw32 --target=mingw32" > when building gcc are > 1) I have, perhaps mistakenly, assumed that "--build=" referred to the OS of > the compiler, > not the ethnicity of the shell. I've assumed it was describing the entire build environment: compiler, yes, linker, yes, but also the surrounding utilities involved in the configuration/compilation process. That's why config.guess uses uname, not $CC -version. I guess that's the nub of the discussion we're having right now: what does it mean when the $build compiler/toolchain is A, but all the other $build tools are B? In seems fragile to assume /either/ build==A, /or/ build==B. > 2) my build gcc is a mingw32 gcc, and unlike a cygwin-hosted gcc, doesn't > understand > symlinks. "--build=cygwin32" would suggest that the native gcc understands > symlinks. > Ditto for my binutil and gdb apps which do not depend on cygwin. Good point. See next para. > 3) specifying "--host=mingw32 --target=mingw32" usually works just fine too > (within a > cygwin bash shell), for most projects, as long as there are no assumptions > about symlinks. Hmmm. When you specify host and target (obviously we're now talking about configuring/building a compiler or part of a compiler toolchain, and not simply Q.Random.Utility.Package; those don't have --target), $build is set implicitly by analyzing the current OS (c.f. config.guess, uname, etc). So, in effect, you're saying that --build=cygwin --host=mingw32 --target=mingw32 works? Again hmmm. So that must mean that (legions of slaving GCC developers) have already set things up in the gcc tree so that symlinks aren't used...ever? Even when $build supports them? > 4) "--build=mingw32 --host=mingw32 --target=mingw32" always seemed to be a > natural way to > do a bootstrap. Certainly. If *everything* about the build environment was, in fact, "mingw" (or, actually, msys in its normal "don't mind me; I'm mingw...really, I am!" mode). But when the toolchain is mingw, but the rest of the $build env is cygwin? Not quite so natural. > I don't set any special environment variables before I "bash ./config.sh" > from a DOS > prompt (my everday path just put C:/mingw/bin in front of C:/cygwin/bin) and > I don't cross > my fingers because I know it has worked for 10 years or so. Yes, I know: you're one of the first people I thought of when this subject came up on the libtool list. I *really* want to make sure that things keep working for you, in the way you expect them to (with maybe only a small tweak to your build.sh ) But I worry that things are (or will soon be) broken already. gcc currently has a snapshot of development libtool from 2007-03-18, with several fixes backported from more recent git. So, presently, the libtool used by gcc does the following, when building an exe that depends on an uninstalled shared library [*]: 1) creates both a wrapper script foo and wrapper exe foo.exe in the build directory, and also (?) a copy of the wrapper script in .libs/ 2) the wrapper exe execs the wrapper script via $SHELL 3) the wrapper script handles all the $PATH manipulations, and locates/execs the "real" exe [*] Doesn't this description apply to most of the tools, and many of the testsuite apps? Now, if libtool is only used to build the libs, and gcc's Makefiles/test harnesses handle everything else without the use of libtool or its wrapper script/wrapper exe system...then whew! maybe we dodged a bullet! [**] Note the context switches involved in old libtool (current gcc libtool): you're in $build, and you launch the $host wrapper exe, which launches the $build $SHELL, which executes the wrapper script in a $build context, which launches the $host "real" exe. This 1-2-3 step process works fine in all the scenarios mentioned; mainly because the "difficult bits" are handled by $SHELL (of whatever flavor) and its underlying runtime (be it cygwin [***], or msys[], or whatever). [***] cygwin's exec() implementation translates many environment variables from posix to win32 format, when the target of the exec() is a non-cygwin application. So, when //bash// execs the real exe, under the hood cygwin translates $PATH. Also, cygwin's exec() implementation translates the unix path-to-real.exe before (eventually) invoking CreateProcess with a win32 path-to-real.exe. [] msys's bash works similarly to cygwin, expecially its interaction with the underlying posix dll's exec implementation. But...this 1-2-3 process never worked in cygwin-1.5 if CYGWIN=transparent_exe (more at the link, below). However, in cygwin-1.7 this has significant problems; the old (optional) transparent_exe behavior is now the default. This means that having both a wrapper script 'foo' and a wrapper exe 'foo.exe' in the same directory is very bad news. See this thread: libtool vs. transparent_exe [Was: [ITP] util-linux] http://sources.redhat.com/ml/cygwin/2006-03/msg00148.html And this one a
Re: RFD: cygwin + *native* MinGW compiler
Charles Wilson wrote:
[describe "old" libtool behavior; what I called "current gcc libtool"]
> 1) creates both a wrapper script foo and wrapper exe foo.exe in the
> build directory, and also (?) a copy of the wrapper script in .libs/
> 2) the wrapper exe execs the wrapper script via $SHELL
> 3) the wrapper script handles all the $PATH manipulations, and
> locates/execs the "real" exe
[contrast new libtool-git-ToT behavior]
> And that's the problem. I have a hunch that *right now*, if we dropped
> in git-master-ToT libtool into gcc, your configure incantation would
> fall over dead, because every executable's wrapper script (if built
> using libtool) would have the "wrong" format of path/to/real/exe inside
> _spawn("...") -- unless we dodged the bullet, as described above.
Wierd. It's been a while since I updated my local svn tree of gcc. It
finally finished, and I see that, in fact, current gcc trunk includes a
much newer version of libtool than I thought (2008-09-26==2.2.6ish, not
2007-03-18). So, in reality, *current* gcc libtool has the "new" behavior.
If that's working for you, Danny, then I guess gcc really did "dodge the
bullet" -- maybe libtool is never used in linking applications or test
progs within the gcc tree, so it's a moot point /for gcc/?
But, all the worries I listed still apply for *other* packages that
someone might want to compile using --build=mingw --host=mingw, when
$build is actually cygwin. But it'd be wonderful to avoid all that
worry for the src/ tree!
--
Chuck
--
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/
/sbin/sysctl question
Is there a way to get /sbin/sysctl -a running on cygwin? I get error: unable to open directory "/proc/sys/" and indeed, there is no sys under proc. Under what conditions is /proc/sys created on cygwin? Ronald -- 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: /sbin/sysctl question
On Jan 29 11:14, Ronald Fischer wrote: > Is there a way to get /sbin/sysctl -a running on cygwin? I get > > error: unable to open directory "/proc/sys/" > > and indeed, there is no sys under proc. Under what conditions is /proc/sys > created on cygwin? There's no implementation of a virtual /proc/sys dir and there are no plans to implement one. As usual, http://cygwin.com/acronyms/#SHTDI and http://cygwin.com/acronyms/#PTC :) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: opengl-1.1.0-10 glut32 linking problems
Hi Reini,
Reini Urban wrote:
> The importlib /usr/lib/w32api/libglut32.a has some problems. Linking
> to the dll directly works fine.
>
> $ cat test.c
> #include
> #include
> #include
> int main(int argc, char *argv[])
> {
> if(glutInit == NULL) {
> printf("glutInit is NULL\n");
> return EXIT_FAILURE;
> }
I really don't know what you are trying to do with that test. glutInit is not
called here, you're only checking the address of that function. As it is not
loaded dynamically, it can only be different from NULL, otherwise linking would
have failed.
> printf("GLUT %d\n",GLUT_API_VERSION);
> return EXIT_SUCCESS;
> }
> $ gcc test.c -lglut32 -lglu -lopengl32
As stated in the opengl-1.1.0-9 and -10 anouncements and in
/usr/share/doc/opengl-1.1.0/README.txt , you must now add
-I/usr/include/opengl at compile time to avoid conflicts with freeglut.
Also, the correct linking for glu is -lglu32. It didn't matter here, but it
will when you
build a more elaborate program. Please check
/usr/share/doc/opengl-1.1.0/README.txt .
> undefined reference to `___glutInitWithExit'
> undefined reference to `___glutCreateWindowWithExit'
> undefined reference to `___glutCreateMenuWithExit'
libglut32.a was part of the w32api package before version 3.13-1 . If you have
w32api-3.12-1 or older, you're getting libglut32.a from the w32api package, not
the one
from the opengl package. The opengl package depends on the w32api package, so
updating the
opengl package should have updated the w32api package first.
What is the result of:
cygcheck -c opengl
cygcheck -c w32api
cygcheck -c libglut3
cygcheck -c libglut-devel
?
> $ gcc test.c /bin/glut32.dll -lglu -lopengl32
>
> $ ./a
> GLUT 3
>
> Note that there are two more ___glut* functions, not only these three.
> $ nm /lib/w32api/libglut32.a | grep " ___glut"
> T ___glutset...@8
> T ___glutinitwithe...@12
> T ___glutget...@4
> T ___glutcreatewindowwithe...@8
> T ___glutcreatemenuwithe...@8
> $ objdump -t /lib/w32api/libglut32.a | grep " ___glut"
> [ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x ___glutset...@8
> [ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x
> ___glutinitwithe...@12
> [ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x ___glutget...@4
> [ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x
> ___glutcreatewindowwithe...@8
> [ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x
> ___glutcreatemenuwithe...@8
>
> I see nothing problematic, but I'm no expert
What is the output of ls -l /usr/lib/w32api/libglut32.a ?
It should match:
Fri Dec 5 15:57:41 2008 90472 usr/lib/w32api/libglut32.a
from the opengl-1.1.0-10 package; otherwise, you have the file from an old
w32api package.
You can also try:
gcc test.c /usr/lib/w32api/libglut32.a -lglu32 -lopengl32
To check if -lglut32 leads to the right thing.
> --
> Reini Urban
HTH,
- André Bleau, Cygwin's volunteer OpenGL package maintainer.
Please direct any question or comment about the OpenGL package to cygwin at
cygwin dot com
_
--
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: find assert
On Jan 28 15:46, Gregory Sharp wrote: > Hi, > > > That makes sense. I changed ENOSHARE to ENOENT throughout. > > I upgraded my cygwin 1.7 today, but cygwin+find+UDFS still > reboots my windows 2000 computer. Here's a question: Did you switch on case sensitivity as per http://cygwin.com/1.7/cygwin-ug-net.html#pathnames-casesensitive ? If yes, change your cygdrive prefix in /etc/fstab to contain the additional option "posix=0, as per http://cygwin.com/1.7/cygwin-ug-net.html#mount-table and try again. The UDF driver in 2K and XP is known for its problems and I, for one, have a hard time with this driver if case sensitivity is switched on. I'm preparing a fix for this problem, but I have no idea if that's the cause of your problem, obviously. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Can't compile Screen: Undefined reference to __imp__ospeed
> I'm using a Perl script, available at > http://www.frexx.de/xterm-256-notes/data/256colors2.pl, to test whether my > terminal is giving me 256 colors. Thanks, this is helpful. > It works when I run it from a vanilla bash > prompt, but not from within Screen, even after I installed your build. OK. Same here. I get a variety of different results with different combinations of Cygwin version (1.5, 1.7), terminal type (DOS, xterm) and with/without screen. Without modification, the only combination that gives 256 colors for me is Cygwin 1.5, xterm, without screen. All others give 8 colors, and the colormap is garbled in the DOS terminals (big surprise). However, in /usr/share/terminfo/s, there is a variety of screen* files, including several named screen-256color*. So it turns out that for me, running TERM=screen-256color screen gives 256 colors, at least in Cygwin 1.5. Can you confirm this? In Cygwin 1.7, I still only get 8 colors. I'll report that separately as a bug. Andrew. -- 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/
read file with windows filenames
Hi, I want to read filenames from a file and manipulate this files with the windows program "attrib". Not easy to find how to read windows filenames from a file without lost of "\". while IFS= read -r cLine do echo "$cLine" done < restoreFiles.tmp The above will work. BUT: while IFS= read -r cLine do echo "$cLine" attrib +H "$cLine" done < restoreFiles.tmp rm -f restoreFiles.tmp will stop the while loop after the first call of attrib: + echo 'C:\Dokumente und Einstellungen\Administrator\Anwendungsdaten\Microsoft\Credentials\S-1-5-21-1606980848-1532298954-1801674531-500' C:\Dokumente und Einstellungen\Administrator\Anwendungsdaten\Microsoft\Credentials\S-1-5-21-1606980848-1532298954-1801674531-500 + attrib +S 'C:\Dokumente und Einstellungen\Administrator\Anwendungsdaten\Microsoft\Credentials\S-1-5-21-1606980848-1532298954-1801674531-500' + IFS= + read -r cLine + test 0 -gt 0 + rm -f restoreFiles.tmp Did anyone know what happens there? Thanks for any hint Matthias -- Don't Panic -- 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: read file with windows filenames
On Thu, 29 Jan 2009, Matthias Meyer wrote: while IFS= read -r cLine do echo "$cLine" attrib +H "$cLine" done < restoreFiles.tmp rm -f restoreFiles.tmp will stop the while loop after the first call of attrib: + echo 'C:\Dokumente und Einstellungen\Administrator\Anwendungsdaten\Microsoft\Credentials\S-1-5-21-1606980848-1532298954-1801674531-500' C:\Dokumente und Einstellungen\Administrator\Anwendungsdaten\Microsoft\Credentials\S-1-5-21-1606980848-1532298954-1801674531-500 + attrib +S 'C:\Dokumente und Einstellungen\Administrator\Anwendungsdaten\Microsoft\Credentials\S-1-5-21-1606980848-1532298954-1801674531-500' + IFS= + read -r cLine + test 0 -gt 0 + rm -f restoreFiles.tmp Did anyone know what happens there? Given that the debug output has "attrib +S" but the code at top has "attrib +H", and that the debug output has "test 0 -gt 0" that the code doesn't have just before the loop exit, it is probably necessary for you to publish the actual code that's failing, even if it has details that you're "100% certain" are irrelevant and unimportant. -- Tim McDaniel, t...@panix.com -- 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/
jmp_buf size?
What is up with the size of jmp_buf? It appears that setjmp.h confuses bytes and ints. _JBLEN should be 13, not 13*4. or #define _JBTYPE to char, but that doesn't work as easily. ? - Jay -- 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: read file with windows filenames
Tim McDaniel wrote:
> Given that the debug output has "attrib +S" but the code at top has
> "attrib +H", and that the debug output has "test 0 -gt 0" that the
> code doesn't have just before the loop exit, it is probably necessary
> for you to publish the actual code that's failing, even if it has
> details that you're "100% certain" are irrelevant and unimportant.
>
Sorry !
The sourcecode (/etc/setAttribute):
#!/bin/sh
while read -r cLine
do
echo $cLine
attrib ${cLine%%:*} "${cLine#*:}"
done < 2restore4
The output:
$ sh -x /etc/setAttribute
+ read -r cLine
+ echo '+S:C:\Dokumente' und
'Einstellungen\Administrator\Anwendungsdaten\Microsoft\Credentials\S-1-5-21-1606980848-1532298954-1801674531-500'
+S:C:\Dokumente und
Einstellungen\Administrator\Anwendungsdaten\Microsoft\Credentials\S-1-5-21-1606980848-1532298954-1801674531-500
+ attrib +S 'C:\Dokumente und
Einstellungen\Administrator\Anwendungsdaten\Microsoft\Credentials\S-1-5-21-1606980848-1532298954-1801674531-500'
+ read -r cLine
+ exit
attached you will find the file (2restore4) which I want read.
br
Matthias
--
Don't Panic
+S:C:\Dokumente und
Einstellungen\Administrator\Anwendungsdaten\Microsoft\Credentials\S-1-5-21-1606980848-1532298954-1801674531-500
+S:C:\Dokumente und
Einstellungen\Administrator\Anwendungsdaten\Microsoft\CryptnetUrlCache\Content\3C83474D61E624A4F9844DF935AFE217
+S:C:\Dokumente und
Einstellungen\Administrator\Anwendungsdaten\Microsoft\CryptnetUrlCache\Content\E04822AD18D472EA5B582E6E6F8C6B9A
+S:C:\Dokumente und
Einstellungen\Administrator\Anwendungsdaten\Microsoft\CryptnetUrlCache\MetaData\3C83474D61E624A4F9844DF935AFE217
+S:C:\Dokumente und
Einstellungen\Administrator\Anwendungsdaten\Microsoft\CryptnetUrlCache\MetaData\E04822AD18D472EA5B582E6E6F8C6B9A
+S:C:\Dokumente und
Einstellungen\Administrator\Anwendungsdaten\Microsoft\CryptnetUrlCache\Content
+S:C:\Dokumente und
Einstellungen\Administrator\Anwendungsdaten\Microsoft\CryptnetUrlCache\MetaData
+S +H:C:\Dokumente und
Einstellungen\Administrator\Anwendungsdaten\Microsoft\Internet Explorer\Quick
Launch\desktop.ini
+S +H:C:\Dokumente und
Einstellungen\Administrator\Anwendungsdaten\Microsoft\Internet
Explorer\Desktop.htt
:C:\Dokumente und
Einstellungen\Administrator\Anwendungsdaten\Microsoft\Internet Explorer\Quick
Launch
+S:C:\Dokumente und
Einstellungen\Administrator\Anwendungsdaten\Microsoft\SystemCertificates\My\Certificates
+S:C:\Dokumente und
Einstellungen\Administrator\Anwendungsdaten\Microsoft\SystemCertificates\My\CRLs
+S:C:\Dokumente und
Einstellungen\Administrator\Anwendungsdaten\Microsoft\SystemCertificates\My\CTLs
+S:C:\Dokumente und
Einstellungen\Administrator\Anwendungsdaten\Microsoft\SystemCertificates\My
+S:C:\Dokumente und
Einstellungen\Administrator\Anwendungsdaten\Microsoft\Credentials
+S:C:\Dokumente und
Einstellungen\Administrator\Anwendungsdaten\Microsoft\CryptnetUrlCache
+S:C:\Dokumente und
Einstellungen\Administrator\Anwendungsdaten\Microsoft\SystemCertificates
+S:C:\Dokumente und Einstellungen\Administrator\Anwendungsdaten\Microsoft
--
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: read file with windows filenames
For what it's worth, I've had intermittent problems with bash and while read loops where the loop aborts after one iteration whenever there's nontrivial code in the loop body, on multiple platforms, not just Cygwin. So this might not be a Cygwin issue. I've never been ble to isolate the problem enough to file a bug report, unfortunately. 2009/1/29 Matthias Meyer : > The output: > $ sh -x /etc/setAttribute > + read -r cLine > + echo '+S:C:\Dokumente' und > 'Einstellungen\Administrator\Anwendungsdaten\Microsoft\Credentials\S-1-5-21-1606980848-1532298954-1801674531-500' > +S:C:\Dokumente und > Einstellungen\Administrator\Anwendungsdaten\Microsoft\Credentials\S-1-5-21-1606980848-1532298954-1801674531-500 > + attrib +S 'C:\Dokumente und > Einstellungen\Administrator\Anwendungsdaten\Microsoft\Credentials\S-1-5-21-1606980848-1532298954-1801674531-500' > + read -r cLine > + exit > -- 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: jmp_buf size?
On Thu, Jan 29, 2009 at 05:07:42PM +, Jay wrote: > >What is up with the size of jmp_buf? >It appears that setjmp.h confuses bytes and ints. >_JBLEN should be 13, not 13*4. >or #define _JBTYPE to char, but that doesn't work as easily. Huh. You would think that the fact that Cygwin's definition of _JBLEN differed from every other definition would have been a clue that something was amiss here. It appears to be an ancient (pre-2000 when I pulled newlib onto sourceware.org) typo but there is no easy way we can change this now. cgf -- 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: Can't compile Screen: Undefined reference to __imp__ospeed
Andrew Schulman writes: > TERM=screen-256color screen > > gives 256 colors, at least in Cygwin 1.5. Can you confirm this? Yes. Beautiful, Andrew. You said you needed text for the release announcement. I'm not sure what it's supposed to look like, but you can use this, if it works: screen-256color: GNU Screen compiled with the --enable-colors256 flag; without this flag, terminals launched from within Screen can only show 16 colors. Depending on your terminal, you may need to launch Screen as 'TERM=screen-256color screen' in order for 256 colors to work. Thanks again, Andrew. -Justin -- 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: MinTTY feature? Or bug?
Lee D. Rothstein wrote: Interesting feature or bug of MinTTY that does not obtain with any other terminal emulator with which I'm familiar. To wit: If you have a running synchronous script or command to the screen and you type ^l (Ctrl-l) it will immediately clear the screen before the ongoing command terminates. My feeling is that it doesn't matter, but that the behavior is different from other virtual terminals. I've had a look at this: it's a feature that MinTTY inherited from PuTTY. PuTTY emulates features of a whole range of terminals from VT100 through to VT510, and also the so-called 'SCO ANSI' (from before SCO became a dirty word). Apparently the latter interprets the echoed ^L as an actual form feed, whereas all the others just do a linefeed. (There's a separate sequence for clearing the screen, which bash sends when it sees a ^L being typed.) The default compatibility setting includes 'SCO ANSI', hence the behaviour you're seeing. I'll take it out in the next release. Andy -- 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: Can't compile Screen: Undefined reference to __imp__ospeed
> screen-256color: GNU Screen compiled with the --enable-colors256 flag; without > this flag, terminals launched from within Screen can only show 16 colors. > Depending on your terminal, you may need to launch Screen as > 'TERM=screen-256color screen' in order for 256 colors to work. OK, thanks. I'll put a new release out soon with 256 colors enabled, at least for Cygwin 1.5. I'm curious: where do you use this? I've been using 8 or 16 colors I guess, for all of this time and never noticed it. I don't colorize my ls output, for example, as I know many people do. If there's a common application for this, it would help to point it out to users. A. -- 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: Having problems with bash
syllk wrote: > I am hoping that there is a simple fix to this. I am new to cygwin and tinyos > and when running cygwin it immediately runs with this first line 'bash: [: > /home/Chris: binary operator expected'. With this problem I seem to get > errors whenever I try to 'make' anything. > > If anyone knows how to fix this I would much appreciate it. The simple way to debug Cygwin bash startup problems: 1. Open cmd.exe shell 2. "cd C:\cygwin\bin" or whereever the /bin dir has ended up when you've installed it. 3. "bash --login -i -x" Now bash will print out to the screen all the startup scripts as it executes them. Once you've seen what the failing code is, you can figure out whether it's in /etc/profile or ~/.bashrc or ~/.bash_profile and figure out how to fix it. Are there spaces in your Windows username? cheers, DaveK -- 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: read file with windows filenames
Mark J. Reed wrote:
> For what it's worth, I've had intermittent problems with bash and
> while read loops where the loop aborts after one iteration whenever
> there's nontrivial code in the loop body, on multiple platforms, not
> just Cygwin. So this might not be a Cygwin issue. I've never been
> ble to isolate the problem enough to file a bug report, unfortunately.
Thanks to all.
The problem was a problem of this windows program attrib. /dev/null will
solve this problem. :-)
#!/bin/sh
while read -r cLine
do
echo $cLine
attrib ${cLine%%:*} "${cLine#*:}" < /dev/null
done < 2restore4
br
Matthias
--
Don't Panic
--
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/
Setting Integer Variables in Bash
The text below is from a text file. If I type the commands line-by-line in the bash then the commands work as expected. If I save the commands in a text file and call the script I get the error message: ': not a valid identifier2: declare: 'Red ': not a valid identifier3: declare: 'Green #! /cygdrive/c/cygwin/bin/bash declare -i Red declare -i Green Red=10 Green=$Red+1 echo $Green exit 0 -- View this message in context: http://www.nabble.com/Setting-Integer-Variables-in-Bash-tp21737864p21737864.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: Setting Integer Variables in Bash
On Thu, 29 Jan 2009, whitewall wrote: The text below is from a text file. If I type the commands line-by-line in the bash then the commands work as expected. If I save the commands in a text file and call the script I get the error message: ': not a valid identifier2: declare: 'Red ': not a valid identifier3: declare: 'Green Two error messages. #! /cygdrive/c/cygwin/bin/bash declare -i Red declare -i Green Red=10 Green=$Red+1 echo $Green exit 0 You have a carriage return at the end of each line. bash does NOT consider carriage return to be whitespace, dammit, so it is considered normal characters. So it things, for example, that you're declaring a variable named "Red\r", a four-character name, and it just doesn't allow carriage return in the variable name. The key to recognizing the situation is to see ': not a valid identifier2: declare: 'Red and recognize that there's a carriage return in the middle of the message. The opening ' is just before Red. Its matching closing ' is shown as the start of the line -- because carriage return causes the output display to return to the start of line. So - by default, created files in UNIX file format, not native Windows. - strip out the carriage returns from your existing script -- Tim McDaniel, t...@panix.com -- 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: Setting Integer Variables in Bash
On Thu, Jan 29, 2009 at 5:54 PM, whitewall wrote: > > The text below is from a text file. If I type the commands line-by-line in > the bash then the commands work as expected. If I save the commands in a > text file and call the script I get the error message: > ': not a valid identifier2: declare: 'Red > ': not a valid identifier3: declare: 'Green If you run the script's stderr through od or similar, you will see that what bash is really saying is /path/to/your/file: line 2: declare: 'Red\r': not a valid identifier /path/to/your/file: line 3: declare: 'Green\r': not a valid identifier where the '\r's are carriage returns which cause the cursor to go back and overwrite the first part of the message. Run d2u on your script. > #! /cygdrive/c/cygwin/bin/bash > declare -i Red > declare -i Green > Red=10 > Green=$Red+1 Since you've declared both Green and Red as integer, you should just do Green=Red+1, without the dollar sign. Doing Green=$Red+1 first takes Red's value, which is stored as an integer, expands it back into its decimal string representation, and then reparses it to yield its integer value. I know that in a real script, any efficiency gains will be swamped by I/O, but there's no sense making the shell do extra work. :) -- 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: Can't compile Screen: Undefined reference to __imp__ospeed
Andrew Schulman writes: > I'm curious: where do you use this? Well, I'll admit to some degree that it's yak shaving (http://projects.csail.mit.edu/gsb/old-archive/gsb-archive/gsb2000-02-11.html), but the use case for me is running Screen locally and having multiple terminals open remotely, with a few terminals running Vim on various machines. The yellow color vim uses when running on 16 colors is kind of hard to read, especially on a white background (which I use). There are some good 256-color themes out there (desert256, inkpot), and I wanted to use them. -Justin -- 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: Setting Integer Variables in Bash
On Thu, 29 Jan 2009, Mark J. Reed wrote: On Thu, Jan 29, 2009 at 5:54 PM, whitewall wrote: #! /cygdrive/c/cygwin/bin/bash declare -i Red declare -i Green Red=10 Green=$Red+1 Since you've declared both Green and Red as integer, you should just do Green=Red+1, without the dollar sign. Doing Green=$Red+1 first takes Red's value, which is stored as an integer, expands it back into its decimal string representation, and then reparses it to yield its integer value. There IS one subtle difference. If you're running with "set -x", Green=$Red+1 will echo + Green=10+1 But Green=Red+1 will echo + Green=Red+1 (assuming that you've not changed PS4, IFS, &c &c). You can decide which "set -x" output you like. I found that I preferred the substituted forms, the ones with $this and $that. -- Tim McDaniel, t...@panix.com -- 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/
