desktop-menu-antix broken

[blur13Member]

$ desktop-menu --write-out
Traceback (most recent call last):
  File "/usr/local/bin/desktop-menu", line 693, in <module>
    build_menu()
  File "/usr/local/bin/desktop-menu", line 369, in build_menu
    if not oct(os.stat(currentfile).st_mode & 0o777) == '0o664' or not os.stat(currentfile).st_uid == 0 or not grp.getgrgid(os.stat(currentfile).st_gid).gr_name == "users":
               ^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/home/user-name.icewm/menu-applications'

So there is a / missing between user-name and the .icewm directory.

Checked the gitlab page and saw
“fixed escape characters for updated python3” on 28 Jun 2025

Maybe this has something to do with it?

I have
desktop-menu-antix:
Installed: 0.2.4

It says Version: 3.31 in /usr/local/bin/desktop-menu

This is latest version of antiX full

[anticapitalistaForum Admin]

I’ll take a look.
Seems like there is a missing / after username

FileNotFoundError: [Errno 2] No such file or directory: '/home/anticap.icewm/menu-applications'

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[anticapitalistaForum Admin]

Can you try changing these 2 lines in /usr/local/bin/desktop-menu

lines 361 and 364 to look like this

currentfile = USER_HOME+"/"+Var.Conf_Dir+"/"+Var.App_File

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[RobinMember]

anticapitalista wrote:

Can you try changing these 2 lines in /usr/local/bin/desktop-menu

I wonder whether this change will break -​-write-out-global then. I think this issue needs a deeper revision:

651  if write_out_global:
652     USER_HOME="/usr/share/desktop-menu/"

So basically USER_HOME already has a slash in its end. But maybe not when running the special case -​-write-out merely instead of -​-write-out-global.

Seems, depending on where and how the content of this variable is generated, it sometimes has already this slash, and sometimes not, which is why it is sometimes added and sometimes not. I remember having seen desktop-menu trying to write out globally to ‘/home/user-name//.icewm/menu-applications’ before.

Is it guaranteed that 667 USER_HOME = userhome and 669 USER_HOME = os.environ[‘HOME’] always come without the trailing slash? Depending on the answer, we might succeed already with removing the slash from 352 USER_HOME=”/usr/share/desktop-menu/” to see a stable behaviour. Otherwise the variable needs to get normalised before using it.

(Line number count as of v. 3.32)

Windows is like a submarine. Open a window and serious problems will start.

[Brian MasinickModerator]

I’m not sure that I agree with the idea of adding a / to the end of the various paths; seems like a recipe for more potential problems.

When I echo things like $HOME the PATH shows as /home/masinick, not /home/masinick/

If the standard assumption is that there is no trailing / on a directory name, the components between the directory and the filename can be properly selected and parsed.

There are standard commands to determine these elements: dirname returns the directory name, basename returns the filename.
These are commands. I’m almost positive that there are also programming functions providing similar functions; if not, nearly every programming language offers some kind of call, such as system() to which you can enclose a function to the system call, so either way it’s programmable.

While I’m rusty in the details I can remember including such procedures in many scripts from 25-35 years ago; that capability still exists.

--
Brian Masinick
Alternate "Search B":
This search page

[Brian MasinickModerator]

I grabbed a copy of /usr/local/bin/desktop-menu, put the suggested changes to lines 361 and 364,
and also removed the trailing / from line 652 and scanned, looking for other instances.
I think that was the only one; in any case I removed trailing / and ran the utility and it’s working fine.

--
Brian Masinick
Alternate "Search B":
This search page

[DaveForum Admin]

I ran into this in my rewrite of desktop-menu to better support multiple users.
I am not sure if it is the best way yet, but a check can be added for this.
if USER_HOME[-1] != '/': USER_HOME = USER_HOME+"/"
Edit: Maybe
if USER_HOME[-1] != '/': USER_HOME += "/"

• This reply was modified 1 year, 2 months ago by Dave.

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[RobinMember]

Dave wrote:

I am not sure if it is the best way yet, but a check can be added for this.
if USER_HOME[-1] != ‘/’: USER_HOME = USER_HOME+”/”

Many thanks @Dave for looking into this and the input, I’ll fix this in the productive version of desktop-menu, so you can concentrate on the multi-user support rewrite you are on.

Did some checks already. In all occurrences where HOME is used in this script it adds the slashes explicitly (except for the positions in which anticapitalista has added them above), so it is preferable to guarantee the variable itself doesn’t contain an additional slash behind in the three occurrences where it is generated, precisely like Brian @Masinick already had pointed out.

That should do the trick already:
USER_HOME = USER_HOME.rstrip('/')
to be placed where the string content is generated.

In theory this should be enough to see a stable behaviour, neither creating paths with double slashes nor omitting an expected slash.

I’ll test this approach in situ, and then I’ll send a merge request to @anticapitalista with the needed fix.

EDIT: Actually I’ll apply the rstrip method to the USER_HOME creation directly (for all occurrences where the string is not hard coded) instead of adding it in a separate line modifying the already created variable.

Windows is like a submarine. Open a window and serious problems will start.

[sybokMember]

@Robin: rstrip() is a very nice solution.

Few tips to increase readability:
1) More “portable” way of composing path is ‘os.path.join(segment1, segment2, segment3)’ instead of ‘segment1+r”/”+segment2+r”/”+segment3’.
The former already appears in the code.

2) Opening file for its content access or manipulation:

text = open(file, 'a')
text.write('Something something something very useful\n')
text.close()

better be changed to

with open(file, 'a') as text:
    text.write('Something something something very useful\n')

said to be managing resources better (forgetting|deletion of the close statement).

[RobinMember]

Done. Works fine here, no missing nor extra slashes any longer. @anticapitalista Merge request !15 sent.

@blur13 (and everybody who feels like), if you’d want to do some extra stress testing as an early bird on the fixed version, here you are: desktop-menu ver. 3.33

Windows is like a submarine. Open a window and serious problems will start.

[RobinMember]

sybok wrote:

More “portable” way of composing path is
os.path.join(segment1, segment2, segment3)
…
better be changed to

with open(file, 'a') as text:
    text.write('Something something something very useful\n')

This is actually how I usually implement it. But I think it’s not worth updating all occurrences in the existing script without real need. Never change a running… (and moreover, as mentioned, Dave has a next gen version (with a completely new codebase started from scratch) in the pipe already)

Windows is like a submarine. Open a window and serious problems will start.

[blur13Member]

Thanks everyone for the quick resolution, the new script works.

A few remarks:

Why is global write-out the default?

Global write-out ignores desktop files in .local/share/applications and requires admin privileges. On a multi-user system, why would everyone want the exact same menu? Why not set user write-out as the default to allow user customisation of the users own menu.

On a single user system user write-out is always prefered.

In my opinion, based on the above user write-out should be the default.

[RobinMember]

blur13 wrote:

and requires admin privileges.

It requires root for fixing old wrong file permissions in some places system wide.

Moreover it processes the update of antiX 23 desktop files (package antix23-desktop-files) in the main menu, for this task also root is needed since it relies on dpkg diversion.

It will only ask for root credentials if actually one of these tasks needs to be executed, otherwise it will be running as default user. There is never a need to explicitly call it with sudo, it will ask if permission is required.

blur13 wrote:

Why not set user write-out as the default to allow user customisation of the users own menu.

desktop-menu is run by an apt-hook whenever a new package was installed. The new desktop files need to be added as entries to all users menus, not only to the menu of the user who installed a particular sofware accidentally.

blur13 wrote:

why would everyone want the exact same menu?

This precisely is what Dave is working on in the next gen version of this script. It will be multi-user and multi-locale ready.

Windows is like a submarine. Open a window and serious problems will start.

[blur13Member]

Thanks Robin,

(By default I mean that it is the default command in the users icewm menu file for “refresh menu”. I should also clarify that I might be wrong about this since I heavily modify my antiX installs, but I recall this being one of the changes I always make on a new install.)

I forgot that the menu is automatically updated with an apt-hook every time a new package is installed, for all WMs. This is also one of those things I remove since I find it slows down the install process (considerably, on old systems).

Given that behaviour I suppose the current set-up makes sense.

I still think removing the apt hook, changing to user write out in the refresh menu, and having the user update the menu at his or her convenience is the way to go. The upside of having local desktop files included makes this the better option. In my opinion (obviously, since this is what I do with all installs).

Having read the most recent reply I see that this approach is to some degree being implemented.

[Brian MasinickModerator]

This is a good discussion and regardless of the next update we’ve already made a few improvements.

I do think that the more functionality we can accomplish with ordinary user privileges the more secure the overall approach is. Even when occasional elevated privileges are necessary an authentication step should take place.

Yes, it’s inconvenient to have to authenticate multiple times a day but it beats getting hacked.

I wonder if there is a way to establish an authentication key that remains until the user either logs out or locks the screen, then when logging in or unlocking a new key is created. Each time a lock or logout occurs the key is purged.

Thoughts on this and the overall balance of secure authentication and standard user access most of the time?

--
Brian Masinick
Alternate "Search B":
This search page

[Author]

Posts