Re: WHO'S IN CHARGE OF THE MANUAL????

[mike padlipsky]

--- Jason Thomas <address@hidden> wrote:


> I would bet that if you have removed the map entries from your
> menu.lst
> file then it is not the cause of your problem.

i wouldn't bet on it, since the problem is that once the drive letters
get fouled up _in windows_, they stay fouled up in windows [in my
setup].   what i need to know is whether grub set something somewhere
that will cause the problem to reoccur after i bite the bullet and do
the regediting to fix the drive letters.

sure, the foulup might not be grub's fault, but it did occur right
after i tried the map trick ... and i've wasted a week trying to deal
with it, so i want to be confident that when i do what i have to do to
make it go away, it'll stay away; therefore, i need detailed
information about the map command, not just what's currently in the
manual.

speaking of what's in the manual, b/t/w, note that the 'example' is
pretty much context-free: since it's said to be usable both as a
command and in the 'menu', just where is it supposed to be fit into the
'stanza'?  that may or may not be inferable from the document as a
whole, but sound documentation technique would mention it in the
specific section regardless.

 >It only takes affect  from when it is called. 

clearly.

give or take effect vs. affect....

>.After a reboot it is reset to normal!

the manual -- which i've read and read and read -- doesn't say that
explicitly, although, again clearly, i assumed it would be reset or i
wouldn't have tried it in the first place.   and based on what happened
to me it's not clear to me it is the case that it goes away ... but
it's abundantly clear to me that the manual should say so if it is the
case that it does.

as things now stand, i'd like to know what you base that assertion on. 
have you read the code?  did you write the code?  for that matter, are
you in charge of the manual?

> All this is probably in the mailing list archive as well.

not that i could find.  tho there should be one or two messages from me
somewhere responding to the listed bug to the effect that 'in some
circumstances grub doesn't work' [approx.] and requesting that the map
command be better documented even tho the 'official' response to the
listed bug was 'i can't do anything' [approx.]

> You can also try google. Type in 'grub map' and see that the very
> first
> link contains the same information.
 
1] do you really think i'dve sent the msg i did send if i hadn't done
due diligence?

2]  as noted, said information is incomplete and inadequate.

3] you might try googling padlipsky.  [better yet, google 'padlipsky
ritchie' for openers, then google padlipsky]

4] regardless of whether you wrote the code or are in charge of the
manual, if you are fluent in c  i'd very much appreciate your taking a
look at the code [i haven't written/read c since 1977 and at my age am
not about to reboot myself into that arena] and telling me EXACTLY 
what grub does to make the mapping happen.  what bit/bits are set
where?  does it 'talk' to the bios, muck w/ the mbr, muck w/ the sbr,
what?  [and if it's not implicit in the answer to that one, what makes
you/grub think that the effect won't be persistent?]

or am i going to have to ask dennis to take a look at the code for
me....?




=====
cheers, map

abbreviated '.sig' for alternative address@hidden account 
[nominally only used when lafn's comatose]: 
 'pwp' is still http://www.lafn.org/~ba213/mapstuff.html, 
i'm still trying to be less e-verbose, 
and as always, apologies for the shiftless typing,
but the carpal tunnels are still on the brink of cave-in....

PLEASE 'REPLY ALL' IF I'VE CC'D address@hidden


                
_______________________________
Do you Yahoo!?
Shop for Back-to-School deals on Yahoo! Shopping.
http://shopping.yahoo.com/backtoschool