Hi, I'm using EMERGE_DEFAULT_OPTS="--verbose --ask --spinner" for emerge. Today I tested the first time the eix-sync command and after a couple of time I ask me why my computer doesn't work and why eix-sync isn't ready ??? Then I saw it, eix-sync was waiting on "emerge --sync" which was waiting on my decision to sync or not. But the prompt I never saw with eix-sync. arko vmware-modules # eix-sync * eix-cache doesn't exist. Running update-eix! ... [ ok ] * Removing old portage-cache in /var/cache/edb/dep ... [ ok ] * Running emerge --sync ... y [ ok ] * Copying old /var/cache/eix cache to /var/cache/eix.previous ... [ ok ] * Running update-eix ... [ ok ] Diffing databases (13507 - 13507 packages) j0inty Reproducible: Always Steps to Reproduce: 1.emerge eix >= 13.2 2.set EMERGE_DEFAULT_OPTS="--ask" 3.Run eix-sync Actual Results: eix wait on "emerge --sync" and emerge on your decision Expected Results: eix-sync musst passthru the prompt or ask for the answer if --ask is in use
Duplicate of http://bugs.gentoo.org/show_bug.cgi?id=216424
Since this comes up regularly, maybe we can use /dev/null as input if -v was not given .. that way emerge --ask or any tool that expects input from a terminal will die. Martin, I've commit that change to the svn - feel free to revert/change if you don't like it.
Hi Emil, I wrote me an ebuild-9999 and check out the svn trunk with your changes. Your fix doesn't really help. Now eix-sync stops with a crappy message that emerge --sync isn't avalible because another emerge is running. As you will see below I tried the following. In the /etc/make.conf I setted EMERGE_DEFAULT_OPTS="--ask --verbose --nospinner". eix-sync failed but emerge --sync works. Comment out the line will result in a working eix-sync. [code] arko j0inty # eix-sync * Running emerge --sync ... * Problems running time emerge --sync [ !! ] * emerge --sync failed arko j0inty # emerge --sync Do you want to sync your Portage tree with the mirror at rsync://194.97.4.250/gentoo-portage? [Yes/No] n Quitting. arko j0inty # eix-sync * Running emerge --sync ... * Problems running time emerge --sync [ !! ] * emerge --sync failed arko j0inty # vi /etc/make.conf arko j0inty # eix-sync * Running emerge --sync ... [ ok ] * Copying old /var/cache/eix cache to /var/cache/eix.previous ... [ ok ] * Running update-eix ... [ ok ] Diffing databases (13518 - 13518 packages) [>] == app-portage/eix (9999[?]@30.07.2008; (~)0.13.2 -> (~)9999[4]): Small utility for searching ebuilds with indexing for fast results arko j0inty # [/code] Sorry that I have to say that your patch not really works. It breaks the eix-sync now, but doesn't say WHY !!! That can be really confused for somebody and he search for an error what no error is. regards j0inty
Created attachment 161704 [details] eix-9999.ebuild This is only for dev-tests to check out the actually sources.
My patch wasn't supposed to do anything else, and I did not break anything. emerge will now die and no longer wait forever. A reasonable thing to do, may be to redirect stdout only, so any error-messages can still reach the user. In this case .. !!! "--ask" should only be used in a terminal. Exiting. Or we could make the -v option a default that can be switch off by using -q. But that is not my decision to make, so lets wait for Martin Vaeth to weigh in.
(In reply to comment #5) > > A reasonable thing to do, may be to redirect stdout only, so any > error-messages can still reach the user. [...] > > Or we could make the -v option a default Both is not good, because from the feedbacks I conclude that many users are using eix-sync in a cron-job and rely on its log-file which should thus of course contain stdout and stderr by default. A solution would be to "tee" stderr to logfile and terminal (if this is possible in a standard shell...). (Unless of course the -v option is used in which case no logfile is written anyway). It is a pity that portage's --ask option does not go via stderr: Then we could (if the above "tee" is implemented) omit stdin redirection and let the user interfere interactively as he actually probably wanted - not sure whether this would be a reasonable request to the portage team.
(In reply to comment #6) > > A solution would be to "tee" stderr to logfile and terminal I do this now in current svn trunk; please test or (better) improve the code: Unfortunately, I have not found a clean non-bash way to build a tee-pipeline for stderr such that the exit status of the first program in the pipeline can be checked. (Currently, I misuse two new filedescriptors, one for a redirection of the "original" stdout and one for passing the exit status. In particular, the latter seems to be a rather hackish solution.) Better solutions are appreciated.
(In reply to comment #6) > (In reply to comment #5) > > > > A reasonable thing to do, may be to redirect stdout only, so any > > error-messages can still reach the user. [...] > > > > Or we could make the -v option a default > > Both is not good, because from the feedbacks I conclude that many users are > using eix-sync in a cron-job and rely on its log-file which should thus of > course contain stdout and stderr by default. I would remove the log-file code from eix-sync, so users have to "create" those logs them self by just redirecting the output of eix-sync - or maybe there are people that rather have the output sent to them by mail, so they pipe into mail. It would be flexible, simple and require practically no maintenance.
(In reply to comment #8) > It would be flexible Unfortunately, it is not so flexible: The default behavior (i.e. logging everything but simultaneously showing briefly on screen what is currently going on) cannot be reached by any redirection of the user. People who want the behavior you suggest can use option -v. If I just knew how many people have -v in their /etc/eix-sync.conf like me...
(In reply to comment #9) > (In reply to comment #8) > > It would be flexible > > Unfortunately, it is not so flexible: The default behavior > (i.e. logging everything but simultaneously showing briefly on screen what > is currently going on) cannot be reached by any redirection of the user. > People who want the behavior you suggest can use option -v. If they want everything, they could just pipe the output into tee resp. the equivalent tool available on their platform. If they only want the status messages on screen, but the rest in a log file they are out of luck. Anyways, I can't imagine that there is demand for a option like that. Having status messages on screen and program + status on file is again no problem, users just have to 'tee' everything and grep out the status messages afterwards. To reiterate, I think it is a bad idea to implement all the combinations of output redirection and logfile-writing in eix-sync .. that would be excessive featuritis. Let the user handle it.
Grepping partially unknown output is always a dirty thing and a cause of errors, so I would not advise users to do this. But you are right: There is no serious reason to require separate output. (To be honest, I just did not dare to touch it, because eix-sync had worked this way from the very beginning.) So I cancelled now every redirection (including your </dev/null which is now not necessary, since we have proper user interaction.)
Closing since eix-0.13.3 is now in the tree.
