Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: christophed on August 28, 2011, 06:33:57 PM
-
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)?
-
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.
-
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'
-
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 :D
-
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).
-
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.
-
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.
-
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.
-
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?
-
Then this entire thread is based on the inconsistent use of freedesktop item in a console tool.
-
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.
-
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 ...
-
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"!.
-
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 :)
-
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.
-
I may not represent the typical use case (OnDemand extensions in mostly CLI TinyCore) and it's a small effort for me to edit the wrapper scripts if I know I can't depend on them working automagically in my context.
If creating the icons (which I can imagine is quite hard for a lot of tools) is part of the problem maybe part of the solution could be to make one 'generic' icon for all (non specific) CLI tools?
I hope I don't offend anyone by making these remarks since I'm very new to TinyCore and how it works. It's been a superb distro so far!
-
They could and will work automagically. The infastructure is provided and or will be adjusted. FWIW so too is a generic icon. See /usr/share/pixmaps/core.png. However if an extension maker deems not to use such or only upon request, e.g. mc, then so be it. It will not be for lack of base support.
Your question has brought to light valuable insight from a user's perspective. I hold no hard feelings towards anyone. It is an interesting topic discussion which will make Tiny Core only more capable going forward.
-
I recall that previously when creating ondemand entries one was asked for the binary name, if desired. Perhaps that functionality could be brought back for clí extensions in some form.
-
That too, like the "run in xterm" would require that the end user know in advance such details. Whereas the extension maker would obviously know. Many CLI extensions would benefit from having at least a menu item with cliorx. Of course there would still be some CLI extensions where it would not make sense, specifcally those that require dynamic run time command line arguments.