TCE extension name and executable mismatch...

[Misalf]

The following is actually off topic, but I believe it could be related to the same part of code we just patched (not that it was introduced by the patches), so I figured creating another topic is redundant.

Some extensions that contain a CLI-only app and no *.desktop file, act quite weird if launched via OnDemand menu. Respective apps open in tty1, irresponsible to user input and the text cursor is flashing very quickly.
This can be seen with, at least, rogue.tcz and nano.tcz.

Any way to avoid this, apart from simply not using the Window Managers OnDemand menus for CLI-only apps?

Both rogue and nano depend on ncurses. Could this be a ncurses thing?
In that case, maybe checking for ncurses.tcz in the .dep file could fix this?

Code: [Select]

E=$1
shift 1
if [ "$(grep ncurses.tcz /etc/sysconfig/tcedir/optional/$E.tcz.dep)" ]
then
exec cliorx $E "$@"
else
exec $E "$@"
fi

If there exist apps that depend on ncurses but still provide a GUI, this wouldn't make sense though.

[curaga]

It's a CLI app thing, not a ncurses one.

[Misalf]

Would have been too easy.

[nitram]

Thanks Misalf and curaga for your hard work and expertise.

Major improvement over previous OnDemand functionality.

Removing the tc-functions patch, however, provided the best overall results for CLI apps (no hangs).

Based on testing this patch should be modified or removed, would be happy to test additional changes.

TEST SUMMARY:

1. All patches:
- system error beep when loading certain non-GUIs
     PE-flashdepends
     compiletc
     mkisofs-tools
     squashfs-tools
- rogue loaded but hung system, required killall rogue

2. Comment out from tc-functions patch:
#      else
#         echo "Already loaded. Call from regular menu or terminal."
#         printf "\a"

- system error beeps disappeared
- rogue loaded but still hung, required killall

3. Remove tc-functions patch:
#   else
#      fullpath=`which $1`
#      if [ "$?" -eq 0 ] && `echo $fullpath | grep -qv ondemand`
#      then
#         E=$1
#                       shift 1
#                       exec $E "$@"
#      else
#         echo "Already loaded. Call from regular menu or terminal."
#         printf "\a"
#      fi

- wbar loaded but didn't appear, needed to use run box 'wbar'
- fluid loaded but didn't appear, has no desktop file
- no hangs!

*****
tl;dr

- tested on 6.4rc1, official core.gz and vmlinuz
- /etc/init.d/tc-functions and /usr/bin/ondemand patched as per:
  http://git.tinycorelinux.net/index.cgi?url=Core-scripts.git/commit/&id=afdfcf4ffe17cceacfb2cb5324019fe8bb479cd8
  http://git.tinycorelinux.net/index.cgi?url=Core-scripts.git/commit/&id=ccf7cc647a2dc8ae625821a6e8d569a3f6b26aaf
  http://git.tinycorelinux.net/index.cgi?url=Core-scripts.git/commit/&id=6e33e8283ed64637f2f9ed202bf7f17af716e891
  http://git.tinycorelinux.net/index.cgi?url=Core-scripts.git/commit/&id=a1815ae2a0ed49804734cfee8533a00e81ab76d0

Code: [Select]

Numerous GUI and non-GUI apps tested via Fluxbox OnDemand click menu:
PE-flashdepends (personal non-GUI)
PE-smplayer (personal GUI)
autoconf
automake
beaver2
compiletc
core-remaster
emelfm
evince2
flpicsee
fluff
fluid
gdb
grabber
jpilot
lshw
mfmr (personal GUI)
mkisofs-tools
mupdf
nano
rogue
squashfs-tools
submitqc6
vlc2
wbar
xfe
xfw
xmms
Method:
- OnDemand items created via Apps
- apply patches/reboot
- right-click OnDemand menu items
- GUIs with desktop files should auto-open and populate wbar
- non-GUIs should load into file system
- close GUI
- reload all items via Ondemand
- GUI apps should re-open
- system should not hang/infinite loop regardless of GUI/non-GUI

[Misalf]

I guess it's probably the best to include *.desktop files, containing "Exec=cliorx *APPNAME*", in extensions known to "hang" on tty if launched from the Window Managers OnDemand menus.

[nitram]

Without testing every repository application it's not possible to know the frequency of a similar OnDemand rogue.tcz problem. Should OnDemand not be able to load anything without issue, GUI and CLI? A desktop file for some CLI applications is a workaround, although rogue.tcz loaded fine from OnDemand before the tc-functions patch.

Unless i'm missing something the ondemand patch:
1. Introduced a new problem
2. Doesn't appear to fix anything (all OnDemand issues already fixed with ondemand patch)

Was thinking there should be a way to execute GUI apps only/not CLI, already addressed in tc-functions:

Code: [Select]

launchApp() {
FREEDESKTOP=/usr/local/share/applications
if [ -e "$FREEDESKTOP"/"$1".desktop ]
then
E=`awk 'BEGIN{FS="="}/^Exec/{print $2}' "$FREEDESKTOP"/"$1".desktop`
  E="${E% \%*}"
  shift 1
exec ${E} "$@"

This section of the tc-functions patch only caused error beeps when run from OnDemand and did not provide any functionality, such as an "Already loaded..." popup. So not sure it's purpose:

Code: [Select]

else
echo "Already loaded. Call from regular menu or terminal."
printf "\a"
... especially since an already installed message already exists when attempting to reload an extension from terminal:

Code: [Select]

tc@box:/mnt/sdb3/tce/optional$ tce-load -i rogue.tcz
rogue is already installed!

Hopefully someone else can test to confirm or deny my test findings. As i'm inexperienced and may be missing something, please explain what the tc-functions patch accomplishes that isn't already addressed with the ondemand patch and existing tc-functions script. Thanks.

[Misalf]

*.desktop files, for extensions containing a CLI app with the same file name as the extension, would need to be created by the extension's maintainers when they tested to load their extensions via OnDemand menu and found the containing programs hanging on tty, before submitting the extensions.

Extensions are actually loaded without problem, but execution of the containing apps got troublesome for CLI-only apps. The problem is, how to determine if it's a GUI or CLI app.

Before these patches, containing apps did not get executed without a .desktop file present. It would make no sense though, to create an OnDemand item for those extensions, as they couldn't "just be run" by the user without either running the command twice or first loading the extension via  tce-load -i .

The message "Already loaded. Call from regular menu or terminal." is only visible in CLI if launching a script from  /etc/sysconfig/tcedir/ondemand , where ondemand is unable to know what to execute from within the respective extension (like compiletc.tcz etc.). And "printf "\a"" creates the beep.
"$APPNAME is already installed!" is produced by  tce-load -i $APPNAME .

The problem that was introduced is that the OnDemand feature now "works properly". q:

[nitram]

The problem that was introduced is that the OnDemand feature now "works properly". q:

  Thanks for the explanation. OnDemand now works much better, just not for everything...a conundrum. There does not appear to be an obvious alternative solution, aside from creating desktop files for problematic extensions.

I've experimented with the 'cliorx' command you taught me, which works well for some applications (nano, rogue, nethack) but not others (autoconf, automake). So even if there was a way to foolproof detect GUI vs CLI extensions they still might not execute as intended without a proper deskop file.

Code: [Select]

else
fullpath=`which $1`
if [ "$?" -eq 0 ] && `echo $fullpath | grep -qv ondemand`
then
E=$1
                        shift 1
                        cliorx $E "$@"


[curaga]

OnDemand was originally intended for GUI applications mainly, so a rarely used app, say LibreOffice would not take up boot time. For terminal users who'd like to pass files on the first invocation, it's now better, but for others who used the gui menu as a "tce-load favorites" list, it's worse.

I'm not really sure what to do. Both use cases are valid, but they can't be supported at the same time.

[Misalf]

I'd say that compiling tools shouldn't be called blindly anyway, i.e. not from OnDemand menu, which wouldn't make sense anyway. They run using the path they were executed from.

[Misalf]

[...] but for others who used the gui menu as a "tce-load favorites" list, it's worse.

Since the infinite loop for many extensions was transformed to hang of some apps on tty, I think it's still an improvement for GUI and CLI. The infinite loop was more difficult to kill.

[nitram]

OnDemand was originally intended for GUI applications mainly, so a rarely used app, say LibreOffice would not take up boot time.

If it were up to me i would have GUI apps load and run, CLI just load in the background quietly.

I'm not really sure what to do.

The conundrum. TC could be much simplified by removing OnDemand altogether, yet it is extremely useful for many use cases (eg. old hardware, fast boot). On the flipside, would be nice for the user to have seperate customizable OpenOnDemand and LoadOnDemand menus/functions for maximum flexibility, which would surely come with it's own complications and issues.

Dreamland edit: Apps > OnDemand Maintenance > add item > select item > background load only checkbox.
OnDemand script gets flagged
tc-functions script: if flagged load, else load and execute
Not a programmer so probably easier said than done...

I'd say that compiling tools shouldn't be called blindly anyway, i.e. not from OnDemand menu, which wouldn't make sense anyway.

I've always used OnDemand for compiletc as it's a heavy extension not utiliized on every boot, so to have it in the onboot.lst makes less sense for my use case (slow hardware, frequent boots, not daily compiling).

The infinite loop was more difficult to kill.

This is fixed, infinitely happy 
Huge improvement that occured quite frequently, especially when accidently re-loading an extension from OnDemand. Personally i could do without the tc-functions patch, but am now aware of how it works and can always comment it out anyway. The ondemand script is vastly improved. Thanks again gentlemen.

[Misalf]

On the flipside, would be nice for the user to have seperate customizable OpenOnDemand and LoadOnDemand menus/functions for maximum flexibility, which would surely come with it's own complications and issues.

Sounds like a good idea. But I'd prefer an OnDemand list (as it currently exists) and maybe a "QuickLoad" menu for just loading extensions without executing containing apps.
One could also just create scripts in  /etc/sysconfig/tcedir/ondemand  NOT containing...

Code: [Select]

#!/bin/sh
ondemand -e whatever.tcz "$@"
but

Code: [Select]

#!/bin/sh
tce-load -i whatever.tcz
and call these either from the OnDemand menu or typing their names in a terminal with auto comletition (which I guess you use this for?).

I've always used OnDemand for compiletc as it's a heavy extension not utiliized on every boot, so to have it in the onboot.lst makes less sense for my use case (slow hardware, frequent boots, not daily compiling).

You can still load it that way, apart from the fact that it beeps because no executable can be found with the name "compiletc".

[nitram]

compiletc.tcz was an example, there are many CLI extensions that aren't optimal to run when loaded even if 'cliorx' works. Based on current OnDemand list:

- lshw.tcz runs as regular user when launched but is best run as root
- gdb.tcz launches debugger, selecting quit closes terminal/doesn't stay open, not even sure what directory it opens to
- rogue.tcz launches new game, user meaning to resume saved game must close new game, re-open terminal in game save directory
- nano.tcz opens empty file without arguments, user needs to close/re-open terminal to edit an existing file 'nano file_name'
- submitqc6 starts running as regular user, although it appears better to run as root otherwise get 'can't delete temp files' error

Manually editing ondemand scripts is useful, although maybe not appropriate for new users. We all seem to agree the existing setup is not optimal and further tweaking may be beneficial, either from a development perspective or user hack methods. We also see a benefit from having seperate auto-open vs load only options. You prefer manual editing, i think it would be better in the long run to implement changes globally for the benefit of all.

Wouldn't adding another sub-menu for QuickLoad/LoadOnDemand require re-compiling window managers?

Not sure how complicated something like this would be to implement:
- Apps > OnDemand Maintenance > add item > select item > radio button toggle for 'load and open', 'load in background'
- Apps auto-generates ondemand script based on choice, 'ondemand -e whatever.tcz "$@"' or 'tce-load -i whatever.tcz'
- OnDemand menu checkmarks extensions marked 'load and open' (no need for a 2nd OnDemand sub-menu)
- select OnDemand menu item, tc-functions executes either 'ondemand -e whatever.tcz' or 'tce-load -i whatever.tcz'
- re-open Apps anytime user wants to toggle 'load and open' and 'load in background'

Anyway i don't expect this to happen as it would likely require a fair amount of work. Would be happy to test though. Thanks.

[Misalf]

Hello again.
I was about to provide additional fixes for the ondemand feature, but it seems the latest fixes have been reverted or weren't applied to Core 7.x x86. ?

I mean these:

+ Quoted command options in  launchApp()  function and  /usr/bin/ondemand  (also fixes newly created ondemand-scripts).
+ Use  launchApp()  instead of  exec  in  /usr/bin/ondemand , so  .desktop  files are always respected.
+ Prevent  /usr/bin/ondemand  from running ondemand-scripts (infinite loop).

If they were just MIA, here is more:

+ Make applications launched via  /usr/bin/ondemand  run in background, so ( /usr/bin/ondemand  and) the  /etc/sysconfig/tcedir/ondemand/extension_name  script can finish, and won't prevent the boot partition from being un-mounted (in case one wants to eject boot media to use the USB or CD, after launching an ondemand entry).
+ Check for  Terminal=true  as well as for  cliorx  in  .desktop  file (Fixes Htop not running ondemand).
+ Allow "=" equal sign in command options from  .desktop  file (changed field selector from "=" to "Exec=").

Attached diffs include both old and new fixes.