Re: /etc/passwd -> /proc/mkpasswd

2004-04-04 Thread Corinna Vinschen 
On Apr  3 19:48, Gerald Villemure wrote:
> I wonder if it would be possible to do something like this:
> 
> /etc/passwd -> /proc/mkpasswd
> /etc/group -> /proc/mkgroup
> 
> These sym links would make the 2 files dynamic and would simplify setup
> somewhat.

OTOH, it would make the layout of these files rather static.  What if
the files should contain accounts from multiple domains?  What if you
want to map a Windows user name with spaces into a Cygwin user name
witout spaces?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
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: /etc/passwd -> /proc/mkpasswd

2004-04-04 Thread Gerald Villemure 
- Original Message - 
From: "Corinna Vinschen" <[EMAIL PROTECTED]>


> On Apr  3 19:48, Gerald Villemure wrote:
> > I wonder if it would be possible to do something like this:
> >
> > /etc/passwd -> /proc/mkpasswd
> > /etc/group -> /proc/mkgroup
> >
> > These sym links would make the 2 files dynamic and would simplify setup
> > somewhat.
>
> OTOH, it would make the layout of these files rather static.  What if
> the files should contain accounts from multiple domains?  What if you
> want to map a Windows user name with spaces into a Cygwin user name
> witout spaces?

I agree the user should have a choice, thats why its a sym link.
If you want custom files then break the sym link and create the files
manualy.

Gérald


--
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/

UDP socket select/recvfrom problem when no server

2004-04-04 Thread Christopher J. White 
I've got a UDP socket application that fails since my
most recent upgrade, I believe from 1.5.9 to 1.5.9-1.

Basic UDP app that fails as follows:

First problem (note, 10.1.1.19 is the local machine):

 - bind 10.1.1.19:5001
 - select() -- no socket ready
 - sendto 10.1.1.19:5000
 - select() -- socket ready
 - recvfrom() -- error, errno = ECONNRESET 

There is no listener on 5000, so the select() should not be signaling
that it is ready...I suspect that's why the recvfrom() fails.

Intersting twists:
 1) sento 10.1.1.42, another machine on the local subnet fails
identically when there is no app listening on port 5000

 1) sendto 10.1.1.xx where xx is a non-existant machine, then 
the select() does not return ready, and thus I never get
to the recvfrom()

If I start the server app on port 5000 at the destination
of sendto (either locally or not) then it runs fine.  It
works even if no data is transmitted.  

I suspect that the destination is returning an ICMP error when the
server is not running and that is what's giving select() something to
look at.  However, it's my understanding that unless I do a connect(),
ICMP errors are not propogated to the app.  In addition, errno should
be ECONNREFUSED in this case, and not ECONNRESET.

...cj

-- 

-- Christopher J. White
--
-- chris at (---)
--   grierwhite dot com


Cygwin Win95/NT Configuration Diagnostics
Current System Time: Sun Apr 04 10:37:15 2004

Windows XP Home Edition Ver 5.1 Build 2600 Service Pack 1

Path:   C:\cygwin\home\Chris\bin
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\Ubicom\sdk\tools
c:\Ubicom\ip2ktools\H-i686-pc-cygwin32\bin

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1004(Chris) GID: 513(None)
513(None)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1004(Chris) GID: 513(None)
513(None)544(Administrators)  
545(Users)

SysDir: C:\WINDOWS\System32
WinDir: C:\WINDOWS

HOME = `C:\cygwin\home\Chris'
MAKE_MODE = `unix'
PWD = `/home/Chris/c:/working/software/Proliphix/test/ms'
USER = `Chris'

ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\Chris\Application Data'
CLIENTNAME = `Console'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `BLUEWATER'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
CVSROOT = `:pserver:[EMAIL PROTECTED]:/software'
CYGWIN_ROOT = `\cygwin'
DISPLAY = `127.0.0.1:0.0'
GROUP = `None'
HOMEDRIVE = `C:'
HOMEPATH = `\Documents and Settings\Chris'
HOST = `bluewater'
HOSTTYPE = `i386'
LOGNAME = `Chris'
LOGONSERVER = `\\BLUEWATER'
MACHTYPE = `i386'
MANPATH = 
`/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man:/usr/X11R6/man'
NUMBER_OF_PROCESSORS = `1'
OS = `Windows_NT'
OSTYPE = `posix'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 1, AuthenticAMD'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0801'
PROGRAMFILES = `C:\Program Files'
PROMPT = `$P$G'
REMOTEHOST = `127.0.0.1'
SESSIONNAME = `Console'
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINDOWS'
TERM = `xterm'
TERMCAP = `xterm-r6|xterm|xterm X11R6 
version:am:km:mi:ms:xn:co#100:it#8:li#34:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:ae=^O:al=\E[L:as=^N:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cr=^M:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:do=^J:ei=\E[4l:ho=\E[H:im=\E[4h:is=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:kD=\E[3~:kI=\E[2~:kN=\E[6~:kP=\E[5~:kd=\EOB:ke=\E[?1l\E>:kh=\E[1~:kl=\EOD:kr=\EOC:ks=\E[?1h\E=:ku=\EOA:le=^H:md=\E[1m:me=\E[m:mr=\E[7m:nd=\E[C:rc=\E8:sc=\E7:se=\E[m:sf=^J:so=\E[7m:sr=\EM:ta=^I:te=\E[2J\E[?47l\E8:ti=\E7\E[?47h:ue=\E[m:up=\E[A:us=\E[4m:kb=\010:'
TZ = `EST5EDT4,M4.1.0/2,M10.5.0/2'
USERDOMAIN = `BLUEWATER'
USERNAME = `Chris'
USERPROFILE = `C:\Documents and Settings\Chris'
VENDOR = `intel'
WINDIR = `C:\WINDOWS'
WINDOWID = `6291470'
POSIXLY_CORRECT = `1'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `C:\cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `C:\cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `C:\cygwin/lib'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\moun

Re: difference between mingw and cygwin-mingw

2004-04-04 Thread Larry Hall 
At 11:38 PM 4/2/2004, you wrote:
>Folks,
>
>what is the difference between vanilla mingw and the one shipped with
>cygwin?
>in particular, what is the difference between the gcc compiler flavors?


See .



--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
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: Bogus assumption prevents d2u/u2d/conv/etal working on mixed files.

2004-04-04 Thread Hannu E K Nevalainen 
> From: David Fritz
> Sent: Sunday, April 04, 2004 6:46 AM

> Charles Wilson wrote:
> [...]
> >   (2) it's an attempt to prevent users from permanently
> scrogging binary
> > files.  See: d2u, on a binary file, is an irreversible operation.  So,
> > if you do "d2u *" you'll probably kill something deep inside
> some binary
> > file, and you can't fix it -- unless some minimal safeguards
> are in place.
> >
> >   u2d MAY be reversible -- IF there were no pre-exising \r\n
> > combinations in the file to begin with -- so when (OMG-fixit-)d2u is
> > run, obviously the first '\n' is preceeded by a (newly-added)
> '\r\n', so
> > the prog merrily replaces ALL '\r\n' with '\n'...which MAY fix your
> > oops, but maybe not.
> >
> >
> > So, with the current code, if you snarf the first "line" -- all chars
> > until the first '\n' -- if it's a binary file the odds are pretty low
> > that the immediately-preceeding character is a '\r' -- so d2u as
> > currently coded will bail out, and no harm is done.
> >
> > It doesn't work so well in the other direction -- by the same logic
> > above, you'll almost never bail out early if you run 'u2d' on a binary
> > file -- but if you immediately do a 'd2u' you MIGHT be able to recover.)
> >
> [...]
>
> If detection of binary files is desirable, why not use an
> explicit test with a
> more robust methodology?  GNU grep detects binary files by
> looking for a '\0'
> byte.  Such a test could be used by both d2u and u2d; they could
> bail out with a
> message like "skipping binary file".
>
> Cheers

A more "foolproof" (? does such a thing exist) test would be to disallow
using d2u/u2d on anything in directories found in $PATH. But then that one
has its disadvantages too, but less so IMO.

 I find all this "safety" related stuff be a PITA at times. Any kind of test
is prone to fail at some instances; at other instances just a cause for
confusion most of the time -> a lot of bug-hunting - for so little gain.

 How about running d2u/u2d, say, on a regedit 5 file (ie; mostly ascii but
due to the coding every other character is a NUL)?
 Would that be considered "legal"? IMO it should, a fast and easy way to
strip the garbage - to create a file that can be used with normal tools.

 IMO; stay away from all of this safety thingies, at _LEAST_ allow them to
be bystepped; e.g. --force. I will be using that switch all the time.

 There are a lot of these foolhardy "traps" one can fall into; e.g:
$ cd /;rm -rf *
are you gonna find a "safety" hatch for that too?


 Noo... Please, remove all of these safety checks.
There must be some kind of user sanity presupposition. Or else the tools
soon will be crippled to a state where they are unusable for normal work.

 Make Backups, Not War!  -> MBNW!  ;-P


/Hannu E K Nevalainen, B.Sc. EE - 59+16.37'N, 17+12.60'E

** on a mailing list; please keep replies on that particular list **

-- printf("LocalTime: UTC+%02d\n",(DST)? 2:1); --
--END OF MESSAGE--


--
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: UDP socket select/recvfrom problem when no server

2004-04-04 Thread Hannu E K Nevalainen 
> From: Christopher J. White

> I've got a UDP socket application that fails since my
> most recent upgrade, I believe from 1.5.9 to 1.5.9-1.
> 
> Basic UDP app that fails as follows:
> 

> I suspect that the destination is returning an ICMP error when the
> server is not running and that is what's giving select() something to
> look at.  However, it's my understanding that unless I do a connect(),
> ICMP errors are not propogated to the app.  In addition, errno should
> be ECONNREFUSED in this case, and not ECONNRESET.
> 
> ...cj

May I suggest that you download Ethereal (and winpcap if using windows).
Then capture and analyze traffic, instead of guessing. ;-)
-> ethereal.com

/Hannu E K Nevalainen, B.Sc. EE - 59+16.37'N, 17+12.60'E

** on a mailing list; please keep replies on that particular list **

-- printf("LocalTime: UTC+%02d\n",(DST)? 2:1); --
--END OF MESSAGE--

--
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: cygheap problems, 20040326 snapshot

2004-04-04 Thread Christopher Faylor 
On Sun, Apr 04, 2004 at 12:16:06AM -0500, Mark Blackburn wrote:
>Christopher Faylor wrote:
>>On Fri, Apr 02, 2004 at 08:27:32PM -0500, Mark Blackburn wrote:
>>
>>>Brian Ford wrote:
>>>
On Mon, 29 Mar 2004, Mark Blackburn wrote:

>No it isn't.  I recently tried my own build of cygwin:
>

Could you possibly build it with the attached patch and report the
strace output?  Also, if you could scan
cygwin/winsup/cygwin/how-to-debug-cygwin.txt, it will tell you how to
get a working gdb to debug this.  The output of info dll would be
interesting.  Thanks.
>>>
>>>Unfortunately the failure doesn't occur when things (gdb & cygstart)
>>>are run under strace.  Here's the output when run normally:
>>
>>
>>Use the "error_start" option to the CYGWIN environment variable.  It
>>will cause gdb to pop up when the error occurs.
>
>I tried setting error_start as explained in 
>winsup/cygwin/how-to-debug-cygwin.txt. However, gdb doesn't pop up when 
>this error occurs. All I get is the same error message as before. I'm 
>going to try Pierre's patch next.

configure with "--enable-debugging".

--
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: Bogus assumption prevents d2u/u2d/conv/etal working on mixed files.

2004-04-04 Thread Igor Pechtchanski 
On Sat, 3 Apr 2004, David Fritz wrote:

> Charles Wilson wrote:
> [...]
> >   (2) it's an attempt to prevent users from permanently scrogging binary
> > files.  See: d2u, on a binary file, is an irreversible operation.  So,
> > if you do "d2u *" you'll probably kill something deep inside some binary
> > file, and you can't fix it -- unless some minimal safeguards are in place.
> >
> >   u2d MAY be reversible -- IF there were no pre-exising \r\n
> > combinations in the file to begin with -- so when (OMG-fixit-)d2u is
> > run, obviously the first '\n' is preceeded by a (newly-added) '\r\n', so
> > the prog merrily replaces ALL '\r\n' with '\n'...which MAY fix your
> > oops, but maybe not.
> >
> >
> > So, with the current code, if you snarf the first "line" -- all chars
> > until the first '\n' -- if it's a binary file the odds are pretty low
> > that the immediately-preceeding character is a '\r' -- so d2u as
> > currently coded will bail out, and no harm is done.
> >
> > It doesn't work so well in the other direction -- by the same logic
> > above, you'll almost never bail out early if you run 'u2d' on a binary
> > file -- but if you immediately do a 'd2u' you MIGHT be able to recover.)
> >
> [...]
>
> If detection of binary files is desirable, why not use an explicit test
> with a more robust methodology?  GNU grep detects binary files by
> looking for a '\0' byte.  Such a test could be used by both d2u and u2d;
> they could bail out with a message like "skipping binary file".
>
> Cheers

Why not just call "file"?  ...Before using d2u/u2d?  And then call
"d2u/u2d --force".
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

--
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: zsh and line breaks

2004-04-04 Thread Peter Stephenson 
Bart Schaefer wrote:
> On Apr 2,  5:23pm, Peter A. Castro wrote:
> }
> } On Thu, 1 Apr 2004, Peter A. Castro wrote:
> } 
> } So, now I need a ruling on just where to put this fix.
> 
> I don't know that I can give you a "ruling" but in my opinion it would be
> fine to put this in main.c, appropriately #ifdef'd.

I agree, there's nothing magic about main.c.  The only reason it's short
is because usually it's convenient for as much stuff as possible to be
in zsh.dll, on systems where that needs to exist.  Your case is exactly
the opposite, so main.c is fine.

-- 
Peter Stephenson <[EMAIL PROTECTED]>
Work: [EMAIL PROTECTED]
Web: http://www.pwstephenson.fsnet.co.uk

--
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: Loading gcc-compiled DLL with Java (JNI) crashes when using newer (>1.5.5) cygwin1.dll

2004-04-04 Thread Hans Horn 
>>The correct switch is -mno-cygwin.  -mno-cygwin should be equivalent to
>>building with the mingw compiler unless you try to include cygwin header
>>files or libraries, which is a common mistake.

Chris, sorry that was I typo in my posting!
I used gcc -mno-cygwin rather than -no-cygwin, and this did NOT produce a
working dll
mingw-gcc did!

thx for responding,
H.




--
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: Bogus assumption prevents d2u/u2d/conv/etal working on mixed files.

2004-04-04 Thread GARY VANSICKLE 
>  Noo... Please, remove all of these safety checks.
> There must be some kind of user sanity presupposition. Or else the tools
> soon will be crippled to a state where they are unusable for normal work.

FWIW I'm with Hannu.  Should rm ask you, "Do you *really* want to delete
this file?", or make a backup of every file you delete (ala the Recycle
Bin)?  It should according to the thinking in this thread.



--
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: Running Postgresql 7.4.2 on Windows 2000 with Cygwin !

2004-04-04 Thread Jason Tishler 
Jan,

On Sun, Apr 04, 2004 at 03:15:03PM +0200, JC Jan Christensen wrote:
> and downloaded the file :
> 
> cygipc-2.03-2.tar.bz2
> 
> and installed the cygipc-daemon in the file.

The above is a bad thing to do.  See below for why.

> I have downloaded the file postgresql-7.4.2.tar.gz and unpacked it and
> run the following commands:
> 
> ./configure
> make
> make install

The above just built a version of PostgreSQL against cygserver not
cygipc.

> I have made a shell-script that contains the following lines:
> 
> ipc-daemon2 &

You are running cygipc not cygserver.

> initdb -D /usr/local/pgsql/data
> postmaster -i -n -d 2 -D /usr/local/pgsql/data
> 
> When I run this shell-script I get the following error-message from
> initdb :
> 
> FATAL: could not create shared memory
>segment: Function not implemented
> DETAIL: Failed system call was 
> shmget(key=1, size=1081344, 03600)
> initdb: failed
> 
> What is wrong here ???

You are building against cygserver and running against cygipc.  This is
guaranteed not to work.

>  How can I solve this problem 

Build and run against the same IPC implementation.

My suggestion is to install both the cygipc and postgresql packages via
Cygwin's setup.exe instead of manually installing cygipc and trying to
build your own PostgreSQL version.

Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

--
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: Bogus assumption prevents d2u/u2d/conv/etal working on mixed files.

2004-04-04 Thread Igor Pechtchanski 
On Sun, 4 Apr 2004, GARY VANSICKLE wrote:

> >  Noo... Please, remove all of these safety checks.
> > There must be some kind of user sanity presupposition. Or else the tools
> > soon will be crippled to a state where they are unusable for normal work.
>
> FWIW I'm with Hannu.  Should rm ask you, "Do you *really* want to delete
> this file?", or make a backup of every file you delete (ala the Recycle
> Bin)?  It should according to the thinking in this thread.

That's what the "-i" flag is for. :-)  But guess what?  It's not the
default!
IOW, I agree here.  The safety checks don't work (as I showed in
), and they prevent a
legitimate use of the program.  If you really want to be safe, run "file"
before running "d2u/u2d".  Or, leave the safety checks in, but only if a
"--safe" (or whatever the appropriate name is) flag is given.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

--
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: Bogus assumption prevents d2u/u2d/conv/etal working on mixed files.

2004-04-04 Thread David Fritz 
You guys are missing the point.  Charles Wilson mentioned a side effect of the 
code at issue in the original post and suggested that it was valuable.

Personally, I don't care if they attempt to detect binary files or not.  My 
point was (and is) that: *If detection of binary files is desirable*, then why 
not implement it in a more robust manner and inform the user rather than 
silently skipping "binary" files.

Hannu E K Nevalainen wrote:

From: David Fritz
Sent: Sunday, April 04, 2004 6:46 AM


Charles Wilson wrote:
[...]
 (2) it's an attempt to prevent users from permanently
scrogging binary

files.  See: d2u, on a binary file, is an irreversible operation.  So,
if you do "d2u *" you'll probably kill something deep inside
some binary

file, and you can't fix it -- unless some minimal safeguards
are in place.

 u2d MAY be reversible -- IF there were no pre-exising \r\n
combinations in the file to begin with -- so when (OMG-fixit-)d2u is
run, obviously the first '\n' is preceeded by a (newly-added)
'\r\n', so

the prog merrily replaces ALL '\r\n' with '\n'...which MAY fix your
oops, but maybe not.
So, with the current code, if you snarf the first "line" -- all chars
until the first '\n' -- if it's a binary file the odds are pretty low
that the immediately-preceeding character is a '\r' -- so d2u as
currently coded will bail out, and no harm is done.
It doesn't work so well in the other direction -- by the same logic
above, you'll almost never bail out early if you run 'u2d' on a binary
file -- but if you immediately do a 'd2u' you MIGHT be able to recover.)
[...]

If detection of binary files is desirable, why not use an
explicit test with a
more robust methodology?  GNU grep detects binary files by
looking for a '\0'
byte.  Such a test could be used by both d2u and u2d; they could
bail out with a
message like "skipping binary file".
Cheers


A more "foolproof" (? does such a thing exist) test would be to disallow
using d2u/u2d on anything in directories found in $PATH. But then that one
has its disadvantages too, but less so IMO.
 I find all this "safety" related stuff be a PITA at times. Any kind of test
is prone to fail at some instances; at other instances just a cause for
confusion most of the time -> a lot of bug-hunting - for so little gain.
 How about running d2u/u2d, say, on a regedit 5 file (ie; mostly ascii but
due to the coding every other character is a NUL)?
 Would that be considered "legal"? IMO it should, a fast and easy way to
strip the garbage - to create a file that can be used with normal tools.
Huh?  u2d/d2u will not strip the "garbage".  For that use iconv; as in,

$ iconv -f UTF-16LE -t UTF-8 < in > out


 IMO; stay away from all of this safety thingies, at _LEAST_ allow them to
be bystepped; e.g. --force. I will be using that switch all the time.
 There are a lot of these foolhardy "traps" one can fall into; e.g:
$ cd /;rm -rf *
are you gonna find a "safety" hatch for that too?
 Noo... Please, remove all of these safety checks.
There must be some kind of user sanity presupposition. Or else the tools
soon will be crippled to a state where they are unusable for normal work.
 Make Backups, Not War!  -> MBNW!  ;-P

OLOCA?

[...]

Cheers

--
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: Bogus assumption prevents d2u/u2d/conv/etal working on mixed files.

2004-04-04 Thread Charles Wilson 
David Fritz wrote:
You guys are missing the point.  Charles Wilson mentioned a side effect 
of the code at issue in the original post and suggested that it was 
valuable.
I think there is some misunderstanding about the cygutils package.  I 
did not write any of it.(*)  I do not defend any of the design decisions 
that were made by the original coders; it's no skin off my nose -- so 
comments like "It should according to the thinking in this thread." fail 
to move me -- except as a data point that GVanSickle really REALLY 
dislikes the current behavior.

(*) Well, maybe the hexdump program or the silly ascii chart, but it's 
been so long I don't remember anymore.

The d2u/u2d progs were some code I thought, back in the dawn of time, 
would be useful on the cygwin platform -- at least *I* had need of a 
dos2unix converter all the time.  So I found the code, adapted it, and 
put it in my "kit", which was called the "misc" package back then.

Now, I remember, when first porting the code for cygwin, wondering WHY 
it did certain things certain ways -- especially the "check the first 
line and bail out" stuff.  All I could figure, at the time, were the two 
reasons I posted in this thread.

I never said I agree with those reasons -- personally, I hate 'rm -i' 
and the like.  But *I am not willing* to unilaterally change behavior of 
tools that may adversely affect users, without a damn good reason. 
Unfortunately, "it offends a single user's sensibilities" -- even mine 
-- doesn't quite rise to that level.

And THAT's why I asked for more discussion.  I'm getting the feeling 
that a preponderance of users -- at least, the ones actually responding 
to this thread -- dislike the current behavior, or at least wouldn't 
mind a change away from the current Microsoft-Bob-like behavior.  I'd 
like to see what some other users, who haven't yet stated their 
opinions, have to say...

--
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/

Re: Bogus assumption prevents d2u/u2d/conv/etal working on mixed files.

2004-04-04 Thread Karl M 
Hi All...

I too would favor that the d2u and u2d just do what I say.

Failing that, instead of --force, could we use 
--please-o-please-convert-this-file-i-really-mean-it

perhaps the I should be capitalized.

Thanks,

...Karl


From: Charles Wilson <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Bogus assumption prevents d2u/u2d/conv/etal working on mixed 
files.
Date: Mon, 05 Apr 2004 00:32:36 -0400

David Fritz wrote:
You guys are missing the point.  Charles Wilson mentioned a side effect of 
the code at issue in the original post and suggested that it was valuable.
I think there is some misunderstanding about the cygutils package.  I did 
not write any of it.(*)  I do not defend any of the design decisions that 
were made by the original coders; it's no skin off my nose -- so comments 
like "It should according to the thinking in this thread." fail to move me 
-- except as a data point that GVanSickle really REALLY dislikes the 
current behavior.

(*) Well, maybe the hexdump program or the silly ascii chart, but it's been 
so long I don't remember anymore.

The d2u/u2d progs were some code I thought, back in the dawn of time, would 
be useful on the cygwin platform -- at least *I* had need of a dos2unix 
converter all the time.  So I found the code, adapted it, and put it in my 
"kit", which was called the "misc" package back then.

Now, I remember, when first porting the code for cygwin, wondering WHY it 
did certain things certain ways -- especially the "check the first line and 
bail out" stuff.  All I could figure, at the time, were the two reasons I 
posted in this thread.

I never said I agree with those reasons -- personally, I hate 'rm -i' and 
the like.  But *I am not willing* to unilaterally change behavior of tools 
that may adversely affect users, without a damn good reason. Unfortunately, 
"it offends a single user's sensibilities" -- even mine -- doesn't quite 
rise to that level.

And THAT's why I asked for more discussion.  I'm getting the feeling that a 
preponderance of users -- at least, the ones actually responding to this 
thread -- dislike the current behavior, or at least wouldn't mind a change 
away from the current Microsoft-Bob-like behavior.  I'd like to see what 
some other users, who haven't yet stated their opinions, have to say...

--
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/
_
Is your PC infected? Get a FREE online computer virus scan from McAfee® 
Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

--
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/