how does ondemand for command line utilities work?

[christophed]

I've installed (frugally) the latest TinyCore onto an aging Thinkpad T23 (PIII with 256 mb of RAM) and I've been playing with it the latest week. So far I like TC a whole lot! It's been a really nice distro so far, and the wiki answers a lot of questions.

I tend to boot into text (framebuffer) mode primarily and start X only when needed (although this is no microcore install!).

I like AppBrowser and AppAudit for installing and marking applications for OnBoot & OnDemand.

But since I want to keep booting fast I want to keep some CLI tools (like mc) OnDemand.

With mc in OnDemand I get (at the console):
aterm: can't open display : 0

When sudoed, mc runs as expected.

Is this expected behaviour and should I be aware of some CLI restrictions to OnDemand (which I've failed to find in the wiki)?

[Rich]

Hi christophed
This is just a guess on my part. I think you need to run the  mc  script in  /home/tc/.wmx/OnDemand
(case sensitive) to mount the extension the first time you run it. After the first time just  mc should be
enough until the next time you boot.

[roberts]

You have raised a very good but subtle point. Ondemand for CLI.

ondemand was designed for menu selection to load  and run extensions. As menu items it was designed with X in mind. Ondemand are simple wrapper scripts derived from the extension's freedesktop item, .e.g., /usr/local/share/applications/mc.desktop.  They are persistent in your tce directory in the ondemand sub directory

Your PATH should have ondemand listed last.

If you look at mc in the ondemand directory you see a hosting aterm. Calling aterm  without X will result in the case that you have described. This hosting aterm is from the mc freedesktop item.

Since the ondemand scripts are persistent, you can edit it. Try replacing the last line 'aterm  -e' with 'cliorx'

[christophed]

Thanks a lot Rich and roberts for these quick replies: these were exactly the kind of hints I was looking for!
(editing the mc script in the ondemand directory worked perfectly fine).

Overall I think TinyCore is very beautifully built (and because of it's small nature, it's easy to follow what's going on). Thumbs up 

[christophed]

Related: isn't the wrapper script (after the conditional tce-load) for ondemand applications supposed to launch the application afterwards?

The ondemand wrapper for alpine currently does not do this which means:

1. you type 'alpine' (the wrapper script gets called, tce-load does it's magic')
2. the script is done (without afterwards loading alpine itself)
3. the second time you try to issue 'alpine' the shell stills remembers the 'alpine' location from (1) which means you have to issue a 'hash -r' (as suggested on IRC @tinycorelinux by glc_) for being able to start alpine without absolute paths (/usr/local/bin/alpine).

 

[roberts]

1. Where is the freedesktop item for alpine? Such is required to know how to launch!
    Without such ondemand fallsback to only able to load the extension.

2. tc@dev:~$ echo $PATH
/home/tc/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/mnt/sda1/tce/ondemand

So a second issue of 'alpine' from shell should find /usr/local/bin/alpine before attempting /mnt/sda1/tce/ondemand.




 

[bmarkus]

mc.tcz got freedesktop menu added just by accident on user's request. alpine do not have it as practically all other console tools are missing it.

[roberts]

Then how would alpine be found/located/accessed on a freedesktop system.
How does one use a freedesktop system to access command line programs?

OnDemand menu relies on freedesktop item to know how/what to launch.

Without such then CLI items becomes available for only those who are familiar.

[bmarkus]

Current situation is that most of the CLI programs are missing freedesktop menu as they are console tools. You can define of course .desktop to have in the extension as a requirement to support ondemand.

Typically no icon is available for CLI progs (mc is an exception again), so you must specify prog not to display in DE's menu like Xfce4, LXDE, ... In this case what is the extra information you have in .desktop what is not available otherwise? Name in Spanish, Germanm etc. and the category. Taht's all. So, why to have it?

[roberts]

Then this entire thread is based on the inconsistent use of freedesktop item in a console tool.

[bmarkus]

Then this entire thread is based on the inconsistent use of freedesktop item in a console tool.

A while ago someone asked to add mc icon to WBAR, so I added a freedesktop menu to mc.tcz Personally I also loved it not because of WBAR but I use mc even in LXDE/Xfce4. So it is just an exception. I can imagine further exceptions when a unique CLI application may have a freedesktop menu, but it is not typical and must be taken as an exception, that's all.

The only proper expectation that CLI tools do not have freedesktop menu.

[maro]

Come to think of it, I know of even a little shell script (i.e. 'wifi.sh') that also comes with an icon (and hence a .desktop file in it's extension).

I guess there will always be good reasons to have a few exceptions here or there ...

[roberts]

By my very remark about alpine, is that even command line extensions could benefit from having a freedesktop item, as base utilities would know how to handle their successful launch. In particular it would not be helpful if wifi.sh was "hidden"!.

[bmarkus]

By my very remark about alpine, is that even command line extensions could benefit from having a freedesktop item, as base utilities would know how to handle their successful launch. In particular it would not be helpful if wifi.sh was "hidden"!.

This means that all LINUx console tools are hidden

You can say alpine is just another execption next to mc. For a packager to find or ctrate a usable is nightmare. Most of us are not Graphics Designers. See TC icons history

[roberts]

If anyone is unable to acknowledge that alpine or other command line extensions could benefit from at minimum a menu to launch cliorx then there is really no point in my trying to innovate further by extending the definition of freedesktop.  I have provided the infrastructure to support this. If the old way of thinking had originally prevailed then there would be no Tiny Core Linux. I am therefore stymied in my endeavor and will refer to maker any complaints about such extensions.