Today I tried to add
Convict Role 0.7 and AnyPet 1.0
(Both on http://bilious.alt.org/)
to vanilla NetHack, but although I followed all the instructions on NetHackWiki
(http://nethackwiki.com/wiki/Patching), it still wouldn't work.When I start patch.exe using a batch file, I only got a blank command line screen with the title C:\***\patch.exe.Five minutes passed, still a blank window.What is the problem??I am using a Win7 system.Is it because the software doesn't work on the system?(http://nethackwiki.com/wiki/Patch says that it has problems on Vista)
Please help me.

Exactly what syntax are you using? Try something like this:
 patch -p0 < whatever.patch

Though I like to do this first:
 patch --dry-run -p0 < whatever.patch
just to make sure everything is OK before making real changes.

He said he followed the instructions, which are:

  patch -p1 < nh343-menucolor.diff

but it seems to me he must have made an error.  The symptom is exactly
what you get if you forget the '<' redirection, and patch starts
waiting for text from the terminal.

Hm, that's not what the instructions say ... OP, did you do *both*, or
didn't you follow the instructions after all?

Seems unlikely that that would give that problem ... but I don't know
much about Windows.

/Jorgen

--
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

Nephi於 2012年7月19日星期四UTC+8下午11時15分40秒寫道：

I used "patch.exe -p1 < file"

Hm, that's not what the instructions say ... OP, did you do *both*, or
didn't you follow the instructions after all?

I tried using a cmd window, but it says "can not find the file"
when I look at the batch window carefully, I see that the "patch.exe -p1 < file"
has turned into "patch.exe -p1 <0file"
I wonder if that is the problem..

I even tried to use the patch command on ophcrack(based on some kind of linux)
but it said that it can not find include/decl.h.

Please quote properly!  I wrote the paragraph above, in reply to the
topmost one.

Which one -- the patch executable or the patch?

Your newsreader (IIRC the new Google Groups with even more bugs)
mangles your text, but not that part, it seems. So it said:

  patch.exe -p1 <0file

Then yes of course that's a problem. Why should it work? Your telling
it the patch it should read is called 0file, and I suspect the file
doesn't have that name.

/Jorgen

--
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

On Thu, 19 Jul 2012 23:37:00 -0700 (PDT), William

 Have you tried making a DOSBox environment and running it from within
that?

 I run all my old legacy PCB layout and CAD apps within that.

  You can point it to a directory and call that "c:" and everything under
it should then also include those error found file directory structures
if you start out with it all under one directory, that is.

I tried to patch it again in the cmd line today.
It says things like "Assertion failed, hunk, file patch.c, line 343,"
I read http://nethackwiki.com/wiki/Patching
"note: On MS-Windows, the patchfile must be a text file, i.e. CR-LF must be used as line endings. A file with LF may give the error: "Assertion failed, hunk, file patch.c, line 343," unless the option '--binary' is given. "
and tried the command "patch.exe --binary -p1 < file"
It jumped out a blank window which disappeared quickly.
I compiled it after that,but it was like I have never patched it.
Am I doing anything wrong?

On Sat, 21 Jul 2012 01:16:23 -0700 (PDT), William

snip

  The patch doesn't take but a second to do.  All it does is change the
files needed to alter the code so that the subsequent compile has the
changes in it.

  The old way was a list of files and the edited strings, etc., and hand
edit sessions.

 All the "patch" does is perform those edits for you so all you need to
do is "patch" and "compile" like you normally do.

 It is because "compilers" were programmers in the early days, and they
knew what was going on.  Nowadays most "compilers" are "users" who have
limited understanding of what is actually going on, but they know how to
go through the simplified compile steps the developers set it up so that
it would be easy for a simple user level person to compile.

SoothSayer於 2012年7月22日星期日UTC+8上午12時04分12秒寫道：

..But,what do I have to do to make it work??

On Sun, 22 Jul 2012 22:55:37 -0700 (PDT), pillow1301300...@gmail.com
wrote:

  Read and try my original response.

  Might work. might not.

 I play Vulture's Eye on my iPad!

  Since it has mouse awareness, it has tap awareness!

 So, I use an RDP to open my windows desktop remotely, and get pure pixel
for pixel performance.

  It is actually the best RDP app I have yet used.

  I was $12  called "iTap RDP".  Pretty awesome.  Of course, I have a bt
keyboard too!

I should take a screen shot of Vulture's Eye on my iPad (a photo
actually) and put it on an iPad chat site or nethack site and watch the
queries for how I did it flow in.

  Hell, I could troll the hell out of them by running impossible apps on
it and posting videos or such. Hehehehehee.*this* RDP app is pretty
tight.

On Jul 19, 5:46 am, William <pillow1301300...@gmail.com> wrote:

Patching and compiling on Windows is certainly possible, but it's
more work (than on other platforms).  Among other things...

Windows doesn't come with patch, so you have to obtain and
install that.  I assume you believe you have done this, but have
you verified that the version of patch you installed works on
your system (e.g., by applying a simple patch to a simple text
file and checking that it applies correctly)?  The wiki article
you cite suggests getting patch from GnuWin32 as a zip archive,
but it neglects to mention that you can't necessarily run
anything from a zip archive.  You have to actually install it.

Windows doesn't come with a compiler either, so you'll need to
obtain and install that too.

Windows doesn't come with basic build tools either (e.g., make),
so you'll need to obtain and install those as well, plus any
other basic system tools that the NetHack build process takes for
granted.  (NetHack comes from the Unix world, so it may just
_assume_ that every computer has stuff like sed and cat and pwd
and touch and tail and so on.  I don't happen to know exactly
what its build process uses, but you may run into things that you
need.)

PATH management on Windows is a royal pain in the neck (due to
fundamental features of the way the directory structure is
organized, which is very different from a Unix layout), so you'll
probably end up having to type full paths to executables on the
command line sometimes.  The instructions may not always indicate
this when it's necessary, because the people who wrote the
instructions either weren't using Windows or had heavily
customized their system, putting dozens of hours into getting
their PATH exactly just so.  (This is difficult because of the
draconian limits Windows places on the length of environment
variables, in combination with the fact that every program you
need adds another directory to the path, not to mention the whole
Progra~1 problem.  When I used Windows on a regular basis, I had
an elaborate set of batch files that managed my PATH for various
kinds of tasks.  The SUBST command was heavily involved.  It was
a nightmare to maintain.  Every time I installed a new utility --
something you do constantly on Windows because it doesn't come
with anything -- I had to figure out how to make room for it in
the PATH.  Fun times.)

NetHack being from the Unix world, you'll probably be working
with some files that have Unix-style line endings (a single
linefeed character instead of the standard ASCII CRLF pair).
These may need to be converted.  The instructions for doing so in
the Wiki article you cited are almost valid but are error prone
and in any case will result in files that have the wrong filename
extension, which an out-of-the-box Windows install will hide from
you by default.  (Anyone who has used Windows extensively will
have turned that particularly ill-conceived feature of Windows
Explorer off a long time ago, but if you don't know what I'm
talking about it implies that you probably haven't done so.)
Besides turning the extension hiding behavior off in the Folder
Options, you may also want to consider using a more reliable
line-ending conversion method in the first place, such as
unix2dos or a proper text editor.

Two things here:

 1. The patch was almost certainly not intended to be used
    in binary mode.  The correct solution is to convert the
    line endings of all the files involved (both the patch
    itself and the source files that it patches) to full
    CRLF pairs.  (They *should* be that way in the first
    place, but stuff from the Unix world often is not,
    especially older stuff, and NetHack is old.)

 2. If you're getting a blank window that disappears
    quickly, something is wrong.  You should not be getting
    a separate window, other than the command window that
    you already have open and are using to run the commands
    in question, which should remain open.  Surely you're
    not trying to do command-line stuff by double-clicking
    on batch files in Windows Explorer?  Because, if you do
    that, you'll never be able to read any error messages to
    find out what's going wrong.  If you're already using a
    command window and a second one opens up, I'm not sure
    what could be causing that.

Am 25.07.2012 14:21, schrieb Jonadab the Unsightly One:

ITYM; "instead of the CRLF pair that is standard on Windows".

Just to be sure no one will falsely assume that CRLF would be
some general standard for text file line terminations.

Janis

On Wed, 25 Jul 2012 16:51:26 +0200, Janis Papanagnou

  Well, SOMEONE should have made a decision that EVERYONE followed about
4 decades ago.

  Same thing happens with idiots behind the wheel of a car.

  Pick any ten, and I can guarantee that you will get ten different
reactions to any given scenario.

  This is the reason why folks buy foreign cars.

  Nobody over here can make up their mind, and any that do will not share
any choices made for fear of being competed with.

  Somebody should come out with a stainless car that lasts for decades.

  No, DMC wasn't it.

On Jul 25, 10:51 am, Janis Papanagnou <janis_papanag...@hotmail.com>
wrote:

No, actually, Unix gets this one wrong.  I'm not a big Windows fan,
but their interpretation of the ASCII spec on this issue is absolutely
correct -- and, I might add, matches the interpretation of most
pre-PostScript printer manufacturers AND most application-layer
network protocols, especially ones that typically run over TCP/IP.

Technically, per the ASCII spec (on which almost all current
text encoding specifications, including Unicode, are based) a
linefeed by itself is a control character that means move directly
down one line, to the character directly under the previous position.

On Jul 25, 9:14 pm, MrTallyman <MrTally...@BananaCountersRUs.org>
wrote:
[Line-ending conventions]

The good news is, CR-only is pretty well dead at this point.
A lot of software (especially text editors) still supports it
as an option, but it's no longer the default on pretty much
anything.

Unix did have a reason for deviating from the spec:
saving one byte per line of text was actually considered
significant at the time.  The good news is, almost all
Unix software can handle standard CRLFs, so bringing
files over from Windows to Unix is seldom a problem.

However, a lot of Unix software still generates LF-only
line endings by default, and some Windows-only software
(very notably, Notepad) does not support that, so taking
Unix files over to a Windows system often necessitates
conversion.

On 26.07.2012 04:09, Jonadab the Unsightly One wrote:

ASCII defines a character set, no more no less. What you would need
is a specification for "text files"; there isn't any. There isn't
any standard for _text file line endings_.

All you derive from that view is arbitrary, so...

This is also not correct; you have to distinguish control character
handling of devices from data format specifications. The first one
depends on the device interpreting the control characters; e.g. ^G
(ASCII BEL, ASCII code 7) rings a bell on some device, flashed on
other devices, does nothing on, again, other devices, and may fire
missile weapons on, again, other devices. WRT text file formats, I
repeat, there is no general specification; most extreme example, but
good enough to make the issue apparent, are main frames which often
had no line terminators at all. You certainly know the contemporary
CR, LF, and CRLF system variants. Some programs even omit a final
line termination at the end of the file; stupid programmers!

ASCII has defined a couple of codes that may be used to control
hardware devices; you gave printers as example. In some old printers
there could be interest to control line feeds individually. But not
generally. E.g. for a teletyper there's with a carriage there's need
for some carriage control code, and for some line feed control code.
For the at that time common line printers (which had one chain with
letter types for each print column!) there is no need for a CR code.
Even for contemporary laser printers there is no necessity for a CR
and no need for LF. But that is about (ASCII or other) control codes
for devices; the issue here is about text file line endings, where
there is no standard. CR, LF, CR-LR, are just used because there was
a feel that it somehow "matches" and (in modern architectures) you
will need to use some non-prinable code.

Janis

On 26.07.2012 04:15, Jonadab the Unsightly One wrote:

Many wrong claims. You should check your sources of wisdom.

Of course; LF is standard on Unix, as CR-LF is standard on
WinDOS, and CR was standard on Macs.

There's still no general standard.

WRT data format specifications; protocols have to define
their data formats for purpose of separation or termination
of records. There's no such beast for text files.

And there's certainly no need to define *two* control codes
for unambiguous separation of text units. And no need to
assume a text file's main purpose is to send it to a printer
with a carriage that you need to position by a CR control
code.

Janis

Am 26.07.2012 07:26, schrieb Jukka Lahtinen:

In the past decades I made two attempts to find one that would
only clarify the line terminator vs. line separator issue; but
to no avail!

(The CR/LF non-standard issue, OTOH, was (to me) quite apparent
given the history of computer systems technology.)

Yes, if Jonadab (or someone else) would be able to provide such
a normative standard (or if only a "quasi-standard") document,
I'd welcome that as well. I doubt, though, that there would be
any attempt recently, since, with the given status quo, you could
never satisfy both of those two established worlds, Unix and MS.

Janis

PS: I notice we're discussing this in the Nethack group; [OT] added.

CR/LF /is/ standard for network transmissions (just like "network byte
order" is), and you'll find POSIXy systems using it even though they use
plain LF for everything else.

I've heard, but don't know of a reliable source, that the original reason
that CR was split from LF is that some old printers couldn't move back to
the start of the line fast enough, and using a two-byte code gave enough
of a delay for them to be able to process the code. It's interesting how
old hacks have such a tendency to propagate.

It's also worth noting that EBCDIC, that famous competitor to ASCII which
ended up losing, had /three/ line-ending-like control codes; linefeed,
carriage return, and newline. (I don't know which were most commonly
used.)

--
ais523

On 26.07.2012 13:58, ais523 wrote:

Not too astonishing, I think. If you consider the teletype devices; they
have a carriage and a role, the carriage can be triggered by the CR and
the role by the LF independently. But I presume by that parallelism you
won't gain too much, since you have to synchronize output of subsequent
characters with a complete returned carriage anyway. But as I mentioned
elsethread, a carriage is not the only output device we had at that time
(or that we have now), and the typical line printers in computer operating
centres were built and working differently.

There's an article in Wikipedia that gives some good insights - wait... -
here it is: http://en.wikipedia.org/wiki/Line_feed
that has even more information about the issue, including the NEL code
that you probably mean.

Also interesting, as I just remembered after my last posting, old printers
(I think it was in a CDC 176 context) used the *ordinary printable character*
in the first column as control code. So a plain character '1' or '2' (don't
recall) in column 1 would issue, say, a paper feed (i.e. ejecting/switching
to the next page); imagine what happens if you route your numerical tables
(by bypassing the driver) to the raw printer device! - Fun, an angry
operator, and a lot of useless paper, maybe to be used in the lavatory only.

Janis

On Jul 26, 1:26 am, Jukka Lahtinen <jtfjd...@hotmail.com.invalid>
wrote:

The American Symbolic Code for Information Interchange

It was published in the sixties by some standards organization or
another and is used by, basically, everything.

Am 27.07.2012 10:31, schrieb Jonadab the Unsightly One:

You should read the details of that spec and ask yourself what it
has to do with a spec for text file line terminators/separators.

In addition I suggest to have a closer look into
http://en.wikipedia.org/wiki/Line_feed
which has very good information and helps to understand the issue.

Janis

On Jul 26, 2:29 am, Janis Papanagnou <janis_papanag...@hotmail.com>
wrote:

Yes, but it defines *meanings* for some of those characters,
including the carriage return and linefeed.  As I noted
upthread, ASCII specifically indicates that the linefeed
means move straight down one line to the position directly
below the previous position.  That's how ASCII printers
treat the character -- which is why you can chuck a DOS text
file out the parallel port and expect the printer to handle
it correctly, but this will not work with a Unix text file.
Dumb terminals (back when people still used such devices)
interpreted the line feed character in the same way, because
that's what the spec says it means.

ASCII doesn't specifically say that you move to the next
line by issuing CR and then LF.  (In fact, LF and then CR
would have exactly the same meaning, per the spec; putting
the CR first is purely a convention.)  What it does specify
is that LF means go straight down one line, without changing
columns, and that CR means go to the beginning of the
current line.  There isn't any single control character in
ASCII for "go to the beginning of the next line".

Obviously, a device can choose to implement or not implement
any given control character, or to substitute equivalent
behavior (such as flashing instead of beeping when no
speaker is available).  That's largely irrelevant to the
question of what the spec says the control character
*means*.

Some newsreaders implement the pagefeed character by
requiring some scroll-down action on the part of the user in
order to view what follows.  Other newsreaders ignore it.
This does not change the fact that the pagefeed character
*means* that the following content is on the next page.

The real clincher for my point is that the people who wrote
almost all of the application-layer network protocols we use
every single day seem to agree with me, since they pretty
much universally specify both CR and LF as necessary to
terminate a line in said protocols.  Most of these people
used Unix and were not unaware of the Unix text file
convention.  You can't send a Unix text file as the body of
an email message without at some point converting it, for
example.  The mail server will send you error codes.  This
goes back ultimately to telnet.

Some mainframe file formats did not have line terminators,
because they were not streams, and there was no transition
from one line to the next -- each line was logically
separate.  (In particular, many record-based formats
specified the length of each field, so no delimiter was
necessary between fields.  The closest modern equivalent is
probably an SQLite DB file, where each "line" of text is a
record.)  This is neither here nor there.  It certainly has
no bearing on the question of what the linefeed character
means, since the files in question did not even use
linefeeds.

Technically, it's not required; however, I would apply here
the rule, "Be strict with what output you generate, liberal
in what input you accept".  The greater mistake is writing
software that does not work correctly if the last line isn't
blank, but since such software is known to exist it's also a
mistake (in most cases) to generate files with a non-blank
last line.

The thing is, the people who wrote Unix were *aware* that
technically a line should end with carriage return and
linefeed.  They chose to omit the carriage return to save a
byte per line.  At the time, this made some sense, because
disk space was a scarce resource -- extremely so, by our
modern standards in this decadent era of seventy-dollar
consumer-grade hard drives that hold half a terabyte or more
and fit in a microcomputer's 3.5-inch internal drive slot,
when companies give out USB Flash drives that hold half a
gigabyte or more and fit in the palm of your hand as free
promotional items.  You tell young people these days that
you once had a ten-megabyte hard drive, and they just assume
you've got your unit sizes confused -- but when Unix was
designed, a drive that large would have supported dozens of
users.