Peculiar difference in starting an application

M

mefizto

Greetings all,

I am posting in this sub-forum because I do not know, which entity, xterm, shell, or Openbox, is responsible for the behavior described below.

I have mail/aerc correctly configured, judging by the fact that when I start xterm (via an Openbox menu), and then invoke mail/aerc from the xterm, it follows the configuration file in that upon attempting checking mail, invokes security/pinentry-curses, which presents a screen to type a passphrase into, which unlocks security/pass and downloads e-mail.

Having that working, I created an item in Openbox menu <command>xterm -e aerc /<command>, but in this case the mail/aerc starts, its system bg mail, but no screen to type a passphrase into appears, and no e-mail is downloaded.

Is there some difference how the Openbox XML parser processes the command, or how the shell executes the mail/aerc behaves?

Any help what might be the culprit so that I can even understand in which direction to search would be appreciated.

Kindest regards,

M
 
I think there are too much possible wrong directions. You have to exclude as much as possible things that can't cause it.
What I know is that you can use x11/xdotool to send simulated keyboard actions to program windows. I can log in to my Hotmail using only a script with key-sequences to the browser. This is relevant to security,though. Don't have this info readable for anything.
 
I had a problem with command substitution (bold highlighted in the first code box) in a execute action keybind.

Perhaps your problem is related.

Here the issue:
Rich (BB code): 
  <keybind key="S-W-Print">
    <action name="Execute">
      <command>maim ~/Pictures/Screenshots/Screenshot-`date '+%F-%T'`.png</command>
     </action>
  </keybind>
This produces Screenshot-`date instead of Screenshot-2026-08-15-00:05:37.png

I found in the Openbox documentation following:
Description
<command> "" A string which is the command to be executed, along with any arguments to be passed to it. The "~" tilde character will be expanded to your home directory, but no other shell expansions or scripting syntax may be used in the command unless they are passed to the sh command. Also, the & character must be written as &amp; in order to be parsed correctly. <execute> is a deprecated name for <command>.
Click to expand...

Here a working execute action, passed to the sh(1) command, in which the command substitution is executed:
Rich (BB code): 
  <keybind key="S-W-Print">
    <action name="Execute">
      <command>sh -c "maim ~/Pictures/Screenshots/Screenshot-`date '+%F-%T'`.png"</command>
     </action>
  </keybind>


In your case try
Rich (BB code): 
<command>sh -c "xterm -e aerc"</command>

EDIT: I just noticed:
mefizto said:
<command>xterm -e aerc /<command>
Click to expand...
The slash in </command> you posted is in a incorrect position, I assume it's a typo.
 
The big thing to keep in mind with openbox is that its clients do NOT inherit the default console session environment. Sometimes it's a real PITA, but I do understand why they do it that way. I end up having create startup scripts for most of my openbox menu items so that the clients get the correct environment when they execute...and trying to properly nest, quote, and escape -e command line options for xterm can drive a person crazy.
 
Hi MG,

thank you for the reply, though as I noted I did not even know where to start, so how can I "exclude as much as possible things that can't cause it"?

Hi willie,

thank you for your reply.

I did try that, and what happened was that the command opened another xterm for the aerc and the original xterm offers a password prompt via pinentry-curses. It seems to confirm kent_dorfman766's answer, see below.

Hi T-Daemon,

thank you for the reply.

Yes, I tried that because I had a similar problem with the aerc.conf, which refused to run script given to it by (even an absolute path) to the *.sh to be executed. It did not work.

Hi kent_dorfman766,

thank you for your reply.

I believe that yours is the right direction. Not only because it confirms by suspicion regarding the shell problem ;), but also because I had to modify the .shrc suggested by a gnupg man-page, which justified need for such a modification by a reference to a difference between a "login" shell and "interactive" shell. As I understand, the primary difference lies in how they are started and which initialization files they load to configure the environment.

Here is the added content:
Code: 
# Set tty for gnupg
GPG_TTY=$(tty)
export GPG_TTY

As best as I understand, the aerc has a control of the xterm, so when the pinentry-curses opens the passphrase prompt ith the same xtem, the gnupg has no notion of the tty. I tried to insert the lines from the .shrc into the Openbox <command>, but I could not make it work. I do not know if it was due to wrong format or the XML parser is not sophisticated enough to interpret the command.

Based on the foregoing, i will try to research how create a script to make the Openbox <command> read the script when invoking the shell.

Kindest regards,

M
 
mefizto said:
but also because I had to modify the .shrc suggested by a gnupg man-page, which justified need for such a modification by a reference to a difference between a "login" shell and "interactive" shell. As I understand, the primary difference lies in how they are started and which initialization files they load to configure the environment.
Click to expand...
I would suggest that you invest some time in understanding that difference. And understand how subshells inherit the environment from the parents. For normal (tty- or ssh-based) login shells this is somewhat simple. Using xterm or similar terminal emulators adds a layer of complexity here, as the xterm program itself must be started from some shell, and it might or might not pass its own environment to the "window" and shell it creates.

To debug, put a well known variable (like foo or FOO) into your various startup files, and make sure it is set when you expect or need it to be.
 
One step forward, two steps back, as comrade Lenin said.

I did created a script:
Code: 
#!/bin/sh
GPG_TTY=$(tty)
export GPG_TTY
exec xterm -e aerc

That did not work, in that the aerc starts, but no passphrase login window is presented. Modifying the script:
Code: 
#!/bin/sh
exec xterm -e sh -c "export GPG_TTY=\$(tty); exec aerc"
works in that it brings the passphrase login window, but it does not respond to input from a keyboard.

Just to confirm that I did not introduce any errors, I returned to starting aerc from an xterm, now the behavior is the same as with the second script, the passphrase login window appears, but it does not respond to input from a keyboard.

I am starting to realize that the solution is beyond my current knowledge; I will have to fall back on (a dirty trick) to first executing mbsync that unlocks the pass database and caches the password, so subsequent invocation of aerc works.

What baffles me is the fact that none of the many blogs implementing pass in aerc mentions this issue. Is Linux so different from FreeBSD?

Kindest regards,

M
 
Hi ralphbsz,

thank you for the answer.

ralphbsz said:
I would suggest that you invest some time in understanding that difference. And understand how subshells inherit the environment from the parents.
Click to expand...
Could you please suggest some references? I really do not know where to start.

Kindest regards,

M
 
You said you're using sh? Then start at "man sh". Look at the section that describes what is an interactive shells and what is a login shell. You can temporarily add some "echo" statements to your .shrc to print out which shell is which. Then read in the same man page about which startup files are read (typically .profile and .shrc). You can also temporarily add echo statements in those places too. Remember to take the echo statements back out, since command execution via ssh often dislikes the shell being chatty.
 
You must log in or register to reply here.
Back
Top