Hi, thanks. Well, after some quick tests the results push me to explain the whole script, which i didn't do at the beginning to just keep to focus on the issue itself without additional bloat, because in any case the error is on the gpg functionality which is used by pass only. So everything i wrote (with some corrections i'll write now) is also reproducible without knowing the full details of my scripts, but we never know they may be useful...
> > i have a script that uses pass [0] password manager, which on his hand > > uses gpg-agent to remember the master passphrase, as you can see. > > Also i have to filter its output, so i pipe it into another script, > > but since i want the output to be unbuffered to get a more real-time > > feedback, i tried calling it this way: > > > > stdbuf -oL pass <pass_arguments> The script actually calls mpop pop3 client, which i set to use its passwordeval functionality to retrieve appropriate passwords for each account from pass password manager. mpop is invoked via stdbuf (to achieve line by line printing) piping its output into another script. So it may be logically represented something like: mpop (=> pass (=> gpg + gpg-agent)) | anotherscript while the actual command in the script is: stdbuf -oL mpop <mpop_arguments> | anotherscript The second part after the pipe should be not relevant at all, since the issue also happens without any piping. The reason i decided to describe the full structure is that in the mpoprc config file, pass is called just with the account i want the password for as argument, such as: passwordeval "pass <my_mail_account>" And this results in the broken pipe error as reported. Anyways i'm not able to get a broken pipe directly calling on a terminal: stdbuf -oL pass <my_mail_account> which whould be equivalent, unless i also use the -c switch (that copies the output to clipboard instead of the stdout). So: stdbuf -oL pass -c <pass_arguments> gives broken pipe. This was the command i was using to test yesterday from the command line, but i tought the -c switch was not relevant so in the quoted command in my first mail i didn't specify it. I decided to describe everything because these last steps seemed weird to me. So to sum up, the broken pipe error is present when mpop calls pass with just the mail account as argument, or on the command line specifying the -c switch too (always invoking them via stdbuf). Another weird thing i noticed is that if i call consecutively multiple times the command line command (the one with -c) discussed above, the error happens one time but not the following, then it shows again and so on alternating almost deterministically, but sometimes it doesn't alternate. > Is that the only difference between your arm device and your x86 device? Yes, this should be the only difference, i keep the two machines synced on most scripts and using the same packages (they are both debian testing too). The kernel is different anyways, it's 3.8.11 on th arm side, if that matters. > From the footer in your bug report, you're using pinentry-curses on the > arm device. is this true for x86 as well, or are you using a different > pinentry there? > > on each machine, what do these show? > > readlink -f /etc/alternatives/pinentry > grep pinentry ~/.gnupg/*.conf > I use pinentry on both. The readlink command shows "/usr/bin/pinentry-curses" while grep finds nothing, on both machines. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
