Re: simplifying rebaseall
I wonder if there could be a more simple way, i.e. putting it into a *.bat script and binding it to an task icon. I am thinking of something in this sense: P:/cygwin/bin/ash --exec /bin/rebaseall As a longterm Linux user I have few experience with windows scripts. Would be nice to have such a script directly linked into the start menu. It's possible to create a link with this adapted to your pathes: %SystemRoot%\system32\cmd.exe /k P:/cygwin/bin/ash /bin/rebaseall Same with an additional user's DLL list: %SystemRoot%\system32\cmd.exe /k P:/cygwin/bin/ash /bin/rebaseall -T /home/prefix/rebase.lst Al -- 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: simplifying rebaseall
I'd beg to differ; I'd suggest it is, as suggested by the OP, actually quite a common use. You only have to look at the use of say perl and you will have users quite regularly compiling their own DLL's as they install modules via CPAN, and this is quite painful due to all the issues it can present with rebase. While I love cygwin, I must say that its supporting community can be very dismissive of its users to the point of alienating potential contributors. I myself has have experienced this on several occasions and have ended up finding myself not raising issues that affect us daily for fear of being shot down for no more reason that someone doesn't think its import to fix or should work that way anyway or even doesn't like the way you structured you post. To reiterate I still think that developers deserve much respect and thanks for all the effort they put in, but a little more open mindedness and approachability like that which can be found in other open source communities such as SFU and FreeBSD wouldn't go a miss sometimes ;-) Regards Steve thanks -- 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: simplifying rebaseall
A second thought. I wonder if reabaseall could be improved to run from within bash, without the need to close down all running windows. Then it could even be included into build scripts to be run after each build. No, because the DLLs used by bash are OFTEN the ones that actually DO need to be rebased (because they are used by darn near everything, so we need to ensure that their image base does not conflict with anything else): libintl, libiconv, libncurses, ... What I suggest isn't that usefull when you think to base all DLL that have been installed by setup.exe. It becomes usefull in the moment the user starts to compile his own DLL especially if he used scripts to control compilation. To compile somethng is a typical use of cygwin. I try to be more precise. Let's call it rebaseplus, but it's code is to 80% similar to rebaseall and duplication of code has known disadvantages. Once rebaseall has been run from ash we can be sure the listed DLLs have sane addresses and bash does work. Now rebaseplus can be run from within bash (and scripts) using a user contributed list of DLL (-T-option). It would base the user contributed DLL into a different address space than rebaseall does. Al -- 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: simplifying rebaseall
On Sat, Sep 18, 2010 at 08:36:28PM +0200, Al wrote: A second thought. I wonder if reabaseall could be improved to run from within bash, without the need to close down all running windows. Then it could even be included into build scripts to be run after each build. No, because the DLLs used by bash are OFTEN the ones that actually DO need to be rebased (because they are used by darn near everything, so we need to ensure that their image base does not conflict with anything else): libintl, libiconv, libncurses, ... What I suggest isn't that usefull when you think to base all DLL that have been installed by setup.exe. It becomes usefull in the moment the user starts to compile his own DLL especially if he used scripts to control compilation. To compile somethng is a typical use of cygwin. No, it really isn't. I try to be more precise. Let's call it rebaseplus, but it's code is to 80% similar to rebaseall and duplication of code has known disadvantages. Once rebaseall has been run from ash we can be sure the listed DLLs have sane addresses and bash does work. Now rebaseplus can be run from within bash (and scripts) using a user contributed list of DLL (-T-option). It would base the user contributed DLL into a different address space than rebaseall does. This isn't a bad idea but it's not really a typical use case. Perhaps you'd like to offer a patch to rebaseall to accomplish this? cgf -- 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: simplifying rebaseall
scripts to control compilation. To compile somethng is a typical use of cygwin. No, it really isn't. I quote wikipedia: Cygwin is used heavily for porting many popular pieces of software to the Windows platform. It is used to compile Sun Java, OpenOffice.org, and even server software, like lighttpd. If that isn't valid any more, it's time to update the article. This isn't a bad idea but it's not really a typical use case. Perhaps you'd like to offer a patch to rebaseall to accomplish this? Sure I offer a patch. Else I wouldn't come up with a suggestion. I need to work on that anyway. Al -- 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: simplifying rebaseall
On Sun, Sep 19, 2010 at 12:43:17AM +0200, Al wrote: On Sat, Sep 18, 2010 at 05:48:07PM -0400, Christopher Faylor wrote: scripts to control compilation. To compile somethng is a typical use of cygwin. No, it really isn't. I quote wikipedia: Cygwin is used heavily for porting many popular pieces of software to the Windows platform. It is used to compile Sun Java, OpenOffice.org, and even server software, like lighttpd. If that isn't valid any more, it's time to update the article. Maybe this will help: http://cygwin.com/dontbelieveeverythingyoureadonrandomsitesaboutcygwin.html cgf -- 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: simplifying rebaseall
- Original Message - From: Christopher Faylor What I suggest isn't that usefull when you think to base all DLL that have been installed by setup.exe. It becomes usefull in the moment the user starts to compile his own DLL especially if he used scripts to control compilation. To compile somethng is a typical use of cygwin. No, it really isn't. I'd beg to differ; I'd suggest it is, as suggested by the OP, actually quite a common use. You only have to look at the use of say perl and you will have users quite regularly compiling their own DLL's as they install modules via CPAN, and this is quite painful due to all the issues it can present with rebase. While I love cygwin, I must say that its supporting community can be very dismissive of its users to the point of alienating potential contributors. I myself has have experienced this on several occasions and have ended up finding myself not raising issues that affect us daily for fear of being shot down for no more reason that someone doesn't think its import to fix or should work that way anyway or even doesn't like the way you structured you post. To reiterate I still think that developers deserve much respect and thanks for all the effort they put in, but a little more open mindedness and approachability like that which can be found in other open source communities such as SFU and FreeBSD wouldn't go a miss sometimes ;-) Regards Steve -- 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: simplifying rebaseall
On Sun, Sep 19, 2010 at 03:52:56AM +0100, Steven Hartland wrote: - Original Message - From: Christopher Faylor What I suggest isn't that usefull when you think to base all DLL that have been installed by setup.exe. It becomes usefull in the moment the user starts to compile his own DLL especially if he used scripts to control compilation. To compile somethng is a typical use of cygwin. No, it really isn't. This isn't a bad idea but it's not really a typical use case. ?Perhaps you'd like to offer a patch to rebaseall to accomplish this? I'd beg to differ; I'd suggest it is, as suggested by the OP, actually quite a common use. You only have to look at the use of say perl and you will have users quite regularly compiling their own DLL's as they install modules via CPAN, and this is quite painful due to all the issues it can present with rebase. We have different definitions of the term typical. The vast VAST majority of people who use Cygwin do not build their own DLLs but they are likely to run into rebase problems. To reiterate I still think that developers deserve much respect and thanks for all the effort they put in, but a little more open mindedness and approachability like that which can be found in other open source communities such as SFU and FreeBSD wouldn't go a miss sometimes ;-) You are responding, for some reason, to one line where I said No, it really isn't and ignoring the rest of the message where I suggested that the OP could provide a patch and they even said they were going to do so. This is pretty typical Cygwin mailing list behavior: ignore the substance and focus on the indignation. It's hardly helpful and it doesn't really get the problem solved. cgf -- 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: simplifying rebaseall
A second thought. I wonder if reabaseall could be improved to run from within bash, without the need to close down all running windows. Then it could even be included into build scripts to be run after each build. Assuming that those DLL which are up and running typically don't need to be rebased, couldn't one simply exclude them from being rebased? I.e. with on option: rebaseall --exclude-loaded Al -- 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: simplifying rebaseall
On 9/17/2010 10:39 AM, Al wrote: A second thought. I wonder if reabaseall could be improved to run from within bash, without the need to close down all running windows. Then it could even be included into build scripts to be run after each build. No, because the DLLs used by bash are OFTEN the ones that actually DO need to be rebased (because they are used by darn near everything, so we need to ensure that their image base does not conflict with anything else): libintl, libiconv, libncurses, ... Assuming that those DLL which are up and running typically don't need to be rebased, couldn't one simply exclude them from being rebased? I.e. with on option: rebaseall --exclude-loaded You're missing the point of rebaseALL. Murphy says that if you don't rebase dll A, then dll A *will* be the culprit the next time you get that 'unable to remap' error. With regards to your earlier .bat file idea...Meh. You shouldn't need to DO it that often -- certainly not often enough to clutter your start menu or desktop with a shortcut! -- Chuck -- 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: simplifying rebaseall
On 9/17/2010 10:50 AM, Charles Wilson wrote: On 9/17/2010 10:39 AM, Al wrote: A second thought. I wonder if reabaseall could be improved to run from within bash, without the need to close down all running windows. Then it could even be included into build scripts to be run after each build. No, because the DLLs used by bash are OFTEN the ones that actually DO need to be rebased (because they are used by darn near everything, so we need to ensure that their image base does not conflict with anything else): libintl, libiconv, libncurses, ... Assuming that those DLL which are up and running typically don't need to be rebased, couldn't one simply exclude them from being rebased? I.e. with on option: rebaseall --exclude-loaded You're missing the point of rebaseALL. Murphy says that if you don't rebase dll A, then dll A *will* be the culprit the next time you get that 'unable to remap' error. With regards to your earlier .bat file idea...Meh. You shouldn't need to DO it that often -- certainly not often enough to clutter your start menu or desktop with a shortcut! And it invites casual use without understanding the what and why. This means more people using it for no reason and more problems using it when it is needed because people don't understand the requirements to make it work (i.e. *nobody* will read the readme... wait, there's a readme? ;-) ). -- 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
Re: simplifying rebaseall
And it invites casual use without understanding the what and why. This means more people using it for no reason and more problems using it when it is needed because people don't understand the requirements to make it work (i.e. *nobody* will read the readme... wait, there's a readme? ;-) ). Hmm, how does information work currently? I found the hint to run rebase somewhere in a blog, when I was hunting down a bug. Others will be told on this list to run rebase all without the hint of a readme. You can verify this be reading the lists archive. The only hint you find in the FAQ is below the topic Terminal Server machine. Who is finding that? I wouldn't even have an idea how to find and read this readme while using ash. I was reading the sources before finding the readme all. I have 10 years of Linux experience and even I didn't expect there was a readme around in this case. If you want to make sure people are informed before running it, it would be an option to display a small text when the script is starting, with the hint to the readme. That would even work with a link from the start menu. If there is a danger that people run rebase all without reading the readme, there is a similar danger that people give up Cygwin, before they ever discover that they could solve their issues by running rebaseall. Al -- 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: simplifying rebaseall
On 9/17/2010 12:18 PM, Al wrote: And it invites casual use without understanding the what and why. This means more people using it for no reason and more problems using it when it is needed because people don't understand the requirements to make it work (i.e. *nobody* will read the readme... wait, there's a readme? ;-) ). Hmm, how does information work currently? Almost EVERYTHING in cygwin has a README. Take a look in /usr/share/doc/Cygwin sometime. Furthermore many packages (but not rebase) have additional documentation in /usr/share/doc/$PKG/ -- just like on linux. I found the hint to run rebase somewhere in a blog, when I was hunting down a bug. Others will be told on this list to run rebase all without the hint of a readme. Because most people, when told to 'run rebaseall' will say to themselves I don't know how to run rebaseall. I wonder if it has a help option... $ rebaseall --help rebaseall: only ash or dash processes are allowed during rebasing Exit all Cygwin processes and stop all Cygwin services. Execute ash (or dash) from Start/Run... or a cmd or command window. Execute '/bin/rebaseall' from ash (or dash). No...but that's a pretty descriptive error message. However, I still want more information. Maybe there's a man page: $ man rebaseall No manual entry for rebaseall $ man rebase No manual entry for rebase Info page? $ info rebaseall $ info rebase No. Well, there must be SOME documentation somewhere. I know: I'll look in the /usr/share/doc $ ls /usr/share/doc/*rebase* ls: cannot access /usr/share/doc/*rebase*: No such file or directory No. Well, Cygwin puts some documentation in /usr/share/doc/Cygwin, so I better look there: $ ls /usr/share/doc/Cygwin/*rebase* /usr/share/doc/Cygwin/rebase-3.0.1.README A-HA! Now, surely that is a lot of hunting around -- but I can only assume that many people did so, since you are apparently the first person to fail to locate the documentation when faced with the question How do I run rebaseall? You can verify this be reading the lists archive. The only hint you find in the FAQ is below the topic Terminal Server machine. Who is finding that? Should we put If you have a question about package foo, be sure and look in /usr/share/doc/foo*/ and at /usr/share/doc/Cygwin/foo* for more information in the signature line of every message? I wouldn't even have an idea how to find and read this readme while using ash. See above. Most of that should be very familiar to a person with 10 years of Linux experience -- except for the bit about Cygwin packages often put a cygwin-specific README file in /usr/share/doc/Cygwin/ Maybe THAT tidbit should go in the FAQ...but I doubt the Questioned is Frequently Asked in this form: Where can I find additional information about specific Cygwin packages. No, the question would be asked Where can I get more information about foo or ...rebase or ..gcc or ...wget So, even if the FAQ *did* have the following: Q: Where can I find additional information about specific Cygwin packages? A: Look in /usr/share/doc/Cygwin/. Most cygwin packages put some cygwin-specific information in a README file located in that directory. ...you still wouldn't have found it -- unless you are in the habit of reading FAQs from top-to-bottom (I'm not...). If there is a danger that people run rebase all without reading the readme, there is a similar danger that people give up Cygwin, before they ever discover that they could solve their issues by running rebaseall. Look, we recognize that this rebase issue has cause *you* heartburn. It annoys us too, but thanks to Bill G, we can't really do anything about it. But, what you have to realize is -- it *does not* always occur. Not *every* user is impacted by it. Many users might use cygwin for years and NEVER see the dreaded unable to remap error. Those people would be in danger of accidentally (or curiously) clicking a shortcut called 'rebase'. The pain of THAT far outweighs the tiny convenience, for a small population of unfortunate newbies, that might need to run rebase but are not yet experienced enough to know all about it. (Worse, we simply CAN'T create a shortcut if the rebase problem hits 'bash' -- all such postinstall scripts themselves will fail with the remap error!) -- Chuck -- 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: simplifying rebaseall
Hi, I appreciate you take the time to contribute all that information. Hope it is not only red by me. Now, surely that is a lot of hunting around -- but I can only assume that many people did so, since you are apparently the first person to fail to locate the documentation when faced with the question How do I run rebaseall? I wasn't faced with that question. I was face with error messages. Google guided me by this messages (and many others) to exactly this blog first: http://www.mylifestartingup.com/2009/04/fatal-error-unable-to-remap-to-same.html ... not to Cygwin list, not to the readme, not to the FAQ. The blog rather tells how to run rebaseall not much why. The comments document well that many people follow that advice without any knowledge of any readme. You don't even find the word readme on that blog. See above. Most of that should be very familiar to a person with 10 years of Linux experience -- except for the bit about Cygwin packages often put a cygwin-specific README file in /usr/share/doc/Cygwin/ It's familiar that regular programs have a doc, man etc. It's also familiar that small maintenance scripts don't have. Even your posting has more lines the he rebaseall script itself. So you wouldn't really follow the search path for docs you give here. That there is a readme for such a small script is the positive execption. But I have doubts that many people will find it. Al -- 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: simplifying rebaseall
On Fri, Sep 17, 2010 at 07:38:03PM +0200, Al wrote: Hi, Hello, It's familiar that regular programs have a doc, man etc. It's also familiar that small maintenance scripts don't have. Even your posting has more lines the he rebaseall script itself. So you wouldn't really follow the search path for docs you give here. That there is a readme for such a small script is the positive execption. But I have doubts that many people will find it. I guess for many people cygwin is their first contact with a *NIX like environment, but given your previous knowledge in Linux, it could also have been and option to inspect the package contents: cygcheck -l rebase Regards. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: simplifying rebaseall
I guess for many people cygwin is their first contact with a *NIX like environment, but given your previous knowledge in Linux, it could also have been and option to inspect the package contents: cygcheck -l rebase It's not only that many people have in Cygwin their first contact with the *NIX world. There is always a point when you have your first contact with a new Distro. cygcheck will be self-evident for every Cygwin insider, but it is foreign for every newcomer, even with 30 years *NIX experience. I see it here the first time. Al -- 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: simplifying rebaseall
On Fri, Sep 17, 2010 at 08:01:23PM +0200, Al wrote: I guess for many people cygwin is their first contact with a *NIX like environment, but given your previous knowledge in Linux, it could also have been and option to inspect the package contents: cygcheck -l rebase It's not only that many people have in Cygwin their first contact with the *NIX world. There is always a point when you have your first contact with a new Distro. cygcheck will be self-evident for every Cygwin insider, but it is foreign for every newcomer, even with 30 years *NIX experience. I see it here the first time. That's true. I used cygwin for a year or so before even noticing cygcheck was there :) I think I started using it after reading http://cygwin.com/problems.html (cygcheck -s -v -r cygcheck.out) But, well, it's more or less the same when you switch from apt/deb to yum/rpm. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: simplifying rebaseall
On 9/17/2010 1:38 PM, Al wrote: Hi, I appreciate you take the time to contribute all that information. Hope it is not only red by me. Now, surely that is a lot of hunting around -- but I can only assume that many people did so, since you are apparently the first person to fail to locate the documentation when faced with the question How do I run rebaseall? I wasn't faced with that question. I was face with error messages. Google guided me by this messages (and many others) to exactly this blog first: http://www.mylifestartingup.com/2009/04/fatal-error-unable-to-remap-to-same.html ... not to Cygwin list, not to the readme, not to the FAQ. The blog rather tells how to run rebaseall not much why. The comments document well that many people follow that advice without any knowledge of any readme. You don't even find the word readme on that blog. But we have no control over that obviously. I think it's important to recognize when you go searching for information, it makes sense to weigh what you find against its source and consider the project's source as a more definitive and complete set of information. Obviously, there's nothing wrong with searching anywhere and everywhere for some clue about a problem. But information that comes from sites that are obviously not the project's site, cygwin.com in this case, is also a clue that further research using the project's resources and the new found data is a good idea. There's no question that there is quite a leap from the error message given to the fact that rebasing is a possible solution (and not the only possible solution - see http://cygwin.com/acronyms/#BLODA for another). A FAQ entry about the remap error message would probably help some at least. Over time, the hope is that package rebuilding helps make this even less of a problem. But it is a pain regardless without a great solution. -- 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
Re: simplifying rebaseall
On Fri, Sep 17, 2010 at 08:01:23PM +0200, Al wrote: I guess for many people cygwin is their first contact with a *NIX like environment, but given your previous knowledge in Linux, it could also have been and option to inspect the package contents: cygcheck -l rebase It's not only that many people have in Cygwin their first contact with the *NIX world. There is always a point when you have your first contact with a new Distro. cygcheck will be self-evident for every Cygwin insider, but it is foreign for every newcomer, even with 30 years *NIX experience. I see it here the first time. If you are using any new distro you have to figure out how to query package information. It is not innate ancestral knowledge that comes from having evolved from hippos. This discussion seems to boil down to Someone should add words about rebaseall to the FAQ. Anyone want to donate some words and suggest where they should go in the FAQ? cgf -- 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: simplifying rebaseall
This discussion seems to boil down to Someone should add words about rebaseall to the FAQ. -bash-3.2$ /bin/rebaseall --help rebaseall: only ash or dash processes are allowed during rebasing Exit all Cygwin processes and stop all Cygwin services. Execute ash (or dash) from Start/Run... or a cmd or command window. Execute '/bin/rebaseall' from ash (or dash). Maybe that info could include a pointer to the doc? Bill -- 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: simplifying rebaseall
This discussion seems to boil down to Someone should add words about rebaseall to the FAQ. If words to the FAQ, then: 1.) a matching header 2.) including link to the readme 3.) including the famous error messages people enter into the search machines: *** fatal error - unable to remap to same address as parent : Then I see some chances that it is found. Al -- 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: simplifying rebaseall
On Fri, Sep 17, 2010 at 11:48:47AM -0700, Bill Ross wrote: This discussion seems to boil down to Someone should add words about rebaseall to the FAQ. -bash-3.2$ /bin/rebaseall --help rebaseall: only ash or dash processes are allowed during rebasing Exit all Cygwin processes and stop all Cygwin services. Execute ash (or dash) from Start/Run... or a cmd or command window. Execute '/bin/rebaseall' from ash (or dash). Maybe that info could include a pointer to the doc? You mean the nonexistent FAQ entry mentioned above? I think most people would find that unhelpful. cgf -- 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: simplifying rebaseall
On Fri, Sep 17, 2010 at 08:49:04PM +0200, Al wrote: This discussion seems to boil down to Someone should add words about rebaseall to the FAQ. If words to the FAQ, then: 1.) a matching header 2.) including link to the readme 3.) including the famous error messages people enter into the search machines: *** fatal error - unable to remap to same address as parent : Then I see some chances that it is found. Hmm. Still no actual *words*. Just the usual propounding. But, yes, if someone does volunteer to write a FAQ entry it should actually be informative. Sorry I didn't make that clear. Next? cgf -- 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: simplifying rebaseall
-bash-3.2$ /bin/rebaseall --help rebaseall: only ash or dash processes are allowed during rebasing Exit all Cygwin processes and stop all Cygwin services. Execute ash (or dash) from Start/Run... or a cmd or command window. Execute '/bin/rebaseall' from ash (or dash). Maybe that info could include a pointer to the doc? You mean the nonexistent FAQ entry mentioned above? I think most people would find that unhelpful. If that is the only doc to point to, then you are right. Alternatively, the recent archives might point to how hard existing docs are to find. -- 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: simplifying rebaseall
If that is the only doc to point to, then you are right. Alternatively, the recent archives might point to how hard existing docs are to find. Good doc is availble. Unfortunatly it is badly linked. http://www.tishler.net/jason/software/rebase/rebase-2.4.2.README It's not the first thing you run into when entering the error messages. *** fatal error - unable to remap to same address as parent : Meanwhile we are in the first page of google whith this thead, when enteringering the message. Good chances that it will be more easy in future due to this effect. :-) Al -- 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
