Hello:

I was convinced I had tried it with and without that -e there, so I checked again.
I was/was not mistaken: the catch is that xterm will open only if there's unread mail.

Clicking on the application icon when it shows mailbox flag in the 'down' position will not open xterm. 

So ...

coolmail -v -e "xterm -xrm 'XTerm.vt100.allowTitleOps: false' -T 'System mail notification' -geometry 120x15-300+150 -e mail"

... works as expected.

I had spent a whole afternoon atempting various combinations, I actually got it to work ...
... but not with mail.

I opened up the configuration file /etc/X11/app-defaults/Coolmail and edited some of the default settings to be able to simplify the command stanza.

groucho@devuan:~$ cat /etc/X11/app-defaults/Coolmail
! Coolmail Application Defaults
!
coolmail.soundFile: /usr/local/bin/sounds/ding.au
!coolmail.frameCount: 10
!coolmail.inbox: /var/spool/mail/username
coolmail.mailCommand: xterm -geometry 120x15-300+150 -e mutt
coolmail.monochrome: False
coolmail*geometry: 76x84-1875+350
coolmail.volume: 100
groucho@devuan:~$ 

With that configuration file I can start up Coolmail in a terminal with :~$coolmail -v.
The application's icon shows up as expected and ~30s after I send myself mail from another terminal, the icon changes.

Clicking on the icon opens up xterm with mutt and I can process the new mail.
Problem is I really don't like mutt and (for the time being), I only need to read my system mail.
I won't be sending mail to anyone, so a terminal with mail is quite enough.

With your heads up, I edited the configuration file to coolmail.mailCommand: xterm -geometry 120x15-300+150 -e mail and now I can say it works.
I worked before but I assumed it did not. 

As expected, I get an xterm window, with the mail label which will do well enough.   
Thanks for that, it did not occurr to me there could be a different behaviour when clicking on the application's icon.

As the system beep set at 100 by coolmail.volume is not loud enough and also confusing, I tried using a *.wav file but I got a "Problem opening/dev/audio" error.
I looked for /dev/audio but it is not there.

groucho@devuan:~$ ls -l /dev/audio
ls: cannot access '/dev/audio': No such file or directory
groucho@devuan:~$

I then converted the file to *.au but got the same result.

The thing is that this really cool application is quite dated.
It was copyrighted back in 1994, so it uses OSS drivers which were dropped from the Linux kernel not too long ago (4.15?).

So I installed the aoss package. https://alsa.opensrc.org/Aoss

With that package installed, starting the application with aoss would solve the sound issue.
But no ...

groucho@devuan:~$ aoss coolmail -v
Coolmail 1.3 watching file: /var/spool/mail/groucho
Coolmail: Error writing to /dev/audio.
groucho@devuan:~$ 

Now, instead of not being able to open /dev/audio it cannot write to /dev/audio.
Thank you for helping me make some headway here.

The only thing pending is getting some audio output from Coolmail.

Best,

A.

A quotable quote if there ever was one.

Hello:

As you indicate, with the back-lash or with the single-quotes it worked.
I did have to move the last double quote to the end of the stanza. otherwise the -geometry bit ie: 120x15 would act upon the application's icon and reduce it to a slit with what would seem to be a 120x15 size ratio.

coolmail -e "xterm -xrm 'XTerm.vt100.allowTitleOps: false' -T 'System mail notification' -geometry 120x15-300+150"

The ideal thing would be to have xterm execute mail/mailx as the window opens, but adding && mail does not work, whether I move the last double quote to the end or not.

More sorcery ... 8^|

How can I get that done?

Thanks a lot for your input.

Best,

A.

Hello:

What I already have installed: exim 4.94.2.  8^D
Sorry, I was not explicit enough about it.

If interested, you can read about my dealings with it here:   https://dev1galaxy.org/viewtopic.php?id=4379
The last post in the thread sums it up in tl;tr: style.

I don't need to forward local mail anywhere, just be notified when mail arrives in my /var/mail/user folder.
Not necessarily in real time (would be nice) just anytime I log in to my desktop.

My box in not up 24/7 and I boot 3 or 4 times a day, so anytime I log in should suffice.

Thanks for your input.

A.

Hello:

UPDATE
I was finally able to get to the bottom of all this exim4 hassle.

Please bear with me, I'll try to be as brief as possible.

When a number of important security failures (dubbed 21 Nails by the IT press) were discovered in exim4 earlier this year, the maintainers were very fast on their feet and an upgraded version 4.94.2 was released almost right away, albeit not without some uproar from the community as this new fixed version actually broke a lot of things for many a sysadmin, things that had been working perfectly well for years.

To the extent that a great many considered opting to downgrade or write risky workarounds.
I have written about this in previous posts, read and check the links if you need more info.

Bottom line?

exim 4.94.2 effectively broke any and all configurations that had been set up with previous versions, whether they used the default configuration ie: the non-split configuration scheme which uses the /etc/exim4/exim4.conf.template file or the split configuration scheme used in more complex installations and which you can eventually opt for when installing Devuan or by running dpkg-reconfigure exim4-config later on.

As a result, from stand alone desktops to production environments to server farms, absolutely everyone updating to exim 4.94.2 was affected.

As mentioned, the default non-split configuration scheme, probably used by 99% of all Devuan/Debian desktops, uses the /etc/exim4/exim4.conf.template which is part of the exim-config package, in turn a dependency of the exim-base package.

The problem I have been bitching about all this time was generated when I updated to exim 4.94.2, something I expected to be a straightforward affaire, without any hassles.

And as (most) any other update, it was.

Half way through, the installer popped up a warning in my terminal informing me that the configuration file being installed ie: the previously mentioned exim4.conf.template was different to the one I had in place and prompted me to choose what to do:

1. keep the installed configuration (default)
2. install the new configuration
3. check and compare the differences.

I chose the default option and in doing so broke my exim4 installation.

As a result my Devuan Beowulf ceased to have a working MTA, all system mail was being held back.
ie: not delivered to my /var/mail/user folder while /var/log/exim4/paniclog slowly grew in size.

I found out about the cause of all this rather by accident.
After not being able to find a solution and fed up with looking, I decided to downgrade exim4 to the previous version and just risk it.

Then, looking at the installed packages, I noticed a discrepancy in their versions ie: exim-config had the previous package version number.

I downloaded and installed the proper version and when the installer warning described above popped up in my terminal, I realised what had happened when I upgraded to 4.94.2.

exim4 is now working as before.

----

Now, after feeling like an idiot for a whole afternoon, I asked myself:

1.
Why would I not choose the default option offered by the installer?

After all, WTF do I know about exim4?
Save that it is the default MTA in Devuan and it keeps me informed as to what is going on via the system mails I get in my /var/mail/user folder, nothing much.

I am not running a mail server from my box and if I add another box to my ADSL router, I believe sending mails between the two boxes is a simple affaire.

Like probably 99% of the Devuan desktops out there, a working default MTA is all I need.

In any case and just like the people who run them, I am just an average user and as such have an inherent trust in everything I download and install from the Devuan repositories, so I had absolutely no reason to choose anything but the default option recommended by the installer.

If I did not have this trust, my box would have something else running inside.

2.
Taking into account that exim 4.94.2 breaks all configurations set up with previous versions of the package ...

rant --->
How is it possible that the exim 4.94.2 installer offers me (as the default and recommended option, no less) to keep a configuration file that, belonging to a previous version, will effectively break it and make it useless?
<--- /rant

From https://www.exim.org/docs.html

From https://git.exim.org/exim.git/blob/HEAD … E.UPDATING

The /etc/exim4/exim4.conf.template file has 2200 lines of code contains a number of $local_part and check_local_user bits.
Unfortunately, editing it by hand did not help me when I did it, so evidently something else was needed.

That's about it.

Best,

A.

Hello:

Done.

Best,

A.

Hello:

One at a time, please, there's room for everyone ...

I think that the problem may lie in the fact that (according to apt) the installed exim4 configuration package ie: exim4-config is not the same version as the rest of the exim4 files in the stable-backports repository:

groucho@devuan:~$ apt list | grep installed | grep exim4

exim4-base/stable-backports,now 4.94.2-5~bpo10+1 amd64 [installed,automatic]
exim4-config/stable,stable,stable-security,stable-security,now 4.92-8+deb10u6 all [installed,automatic]  # <---  | X |    
exim4-daemon-light/stable-backports,now 4.94.2-5~bpo10+1 amd64 [installed,automatic]
exim4/stable-backports,stable-backports,now 4.94.2-5~bpo10+1 all [installed]
groucho@devuan:~$ 

All files are 4.94.2-5~bpo10+1 with the exception of exim4-config which is 4.92-8+deb10u6.

It does not seem to be available:

groucho@devuan:~$ apt list | grep exim4-config
exim4-config/stable,stable,stable-security,stable-security,now 4.92-8+deb10u6 all [installed,automatic]
groucho@devuan:~$ 

[root@devuan groucho]# apt install exim4-config
Reading package lists... Done
Building dependency tree       
Reading state information... Done
exim4-config is already the newest version (4.92-8+deb10u6).
exim4-config set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[root@devuan groucho]# 

The strange thing is that version 4.94.2-5~bpo10+1 is available in http://deb.devuan.org/merged  beowulf-backports/main which is in my sources.list file.

groucho@devuan:~$ cat /etc/apt/sources.list
## package repositories
# Changed - 20210218 - upgrade to Beowulf

# beowulf stable
deb http://deb.devuan.org/merged/ beowulf main contrib non-free 
deb http://deb.devuan.org/merged/ beowulf-security main contrib non-free 
deb http://deb.devuan.org/merged/ beowulf-updates main contrib non-free 

# needed x virtualbox backport - enable to update package
deb http://deb.devuan.org/merged/ beowulf-backports non-free contrib main  

# virtual box repository x installation
# deb http://download.virtualbox.org/virtualbox/debian/ buster non-free contrib 
groucho@devuan:~$ 

Could anyone explain what's going on with my sources.list?

Thanks in advance,

A.

Hello:

For? 8^)

And that's what I understood.
ie: one thing is executing the command listed in crontab from a shell and another is when cron actually executes that command.

Got it.
That command is set up by the application and I have not touched it.
Hence the warning:

#Back In Time system entry, this will be edited by the gui:

Yes, I've seen that some time ago.

In any case, up to now, cron.log has shown no issues with respect to the backintime script.
We'll see if I get some feedback from the GitHub site, it dos not seem to have much activity on behalf of the maintainers.
But it does not seem to be dead.

Thanks so much lot for your input.

Best,

A.

Hello:

It just dawned on me that the solution I linked to comes from the OP comparing his exim.conf with another file called exim.conf.rpmnew.
Very smart.

This other configuration file is included in a distribution (manjaro?) that detected the problem created by the exim4 update and edited the original file accordingly.

Maybe the Devuan/Debian (or better yet, the exim4 packagers may want to consider doing the same with the /etc/exim4/exim4.conf.template file.

Q: should a bug report be filed somewhere?

Best,

A.

Hello:

I think I have found a solution.
I say think because I don't have a clue as to how all this works.
ie: if this is just a workaround or a proper configuration option.

If it is just a workaround the new security schemes in exim4, then it is bound to be temporary and we'll have to be alert.
If it is a proper configuration option, WTF is it not properly documented somewhere?

I found it here:
https://www.linuxquestions.org/question … ost6136422

In this case, the problem seems to be that exim4 now does not like the directory name for my mail folder.
I think it has to do with the backlashes in /var/mail/username.

It would be really nice if whoever came up with this (must be necessary, they know how it all works) just wrote up a small bit or a proper comment inside this file informing that the solution was to edit the file /etc/exim4/exim4.conf.template which is used for the most basic exim4 configuration.
ie: the non-split configuration scheme I expect is used by most of us here at Dev1.

Evidently too much to ask.  8^/

To the point:

The part of this huge 2122 line configuration file that must be edited is the one concerning mail spool configuration.

#####################################################
 ### transport/30_exim4-config_mail_spool
 #####################################################
 
 ### transport/30_exim4-config_mail_spool
 
 # This transport is used for local delivery to user mailboxes in traditional
 # BSD mailbox format.
 #
 mail_spool:
   debug_print = "T: appendfile for $local_part@$domain"
   driver = appendfile
   file = /var/mail/$local_part # <----- this is the line that has to be edited 
   delivery_date_add
   envelope_to_add
   return_path_add
   group = mail
   mode = 0660
   mode_fail_narrower = false
 
 #####################################################
 ### end transport/30_exim4-config_mail_spool
 #####################################################

It seems that the line file = /var/mail/$local_part has to be edited to read  file = /var/mail/$local_part_data.

Sort of makes me wonder if there is any reason for the edited line not being there by default.

Caveat emptor:
I have not tested this yet, the post where I got it had a following one saying that it works.

----> EDIT
For this to work properly the exim4 configuration has to be updated.
BTW: did you see anything about it in the comments at the start of the exim4.conf.template file?
No?
I thought as much ...

As root run:

[root@devuan groucho]# update-exim4.conf -v
using non-split configuration scheme from /etc/exim4/exim4.conf.template
[root@devuan groucho]# jed /etc/exim4/exim4.conf.template

/EDIT <----

I'll post back in a couple of days reboots with the results.

Best,

A.