megaglest-source icon indicating copy to clipboard operation
megaglest-source copied to clipboard

megaglest startscript gives too much output on error

Open titiger opened this issue 8 years ago • 4 comments

When you start mg via command line the startscript adds useless output to the console.

example:

this is ok: ./megaglest --?

the output form this is not ok: ./start_megaglest --?

You get informations about libraries on error which are pretty useless in this case. I suggest that these infos are not displayed for every abnormal returncode.

titiger avatar Jan 29 '16 13:01 titiger

hehe well, every non 0 exit code mean "not ok" :P, so problem begins there where MG's exit code is wrong, basically I am not sure about --? but for sure after official --help exit code should be 0 (not like now is 2 in both cases), ... but still thinking/considering possible workaround I have an important question: does exit code = 2 is unique to situation with "wrong parameters" or may it occur also in other situations?

filux avatar Jan 29 '16 18:01 filux

digging deeper:

  • g3dviewer is always returning exit code 255 also with official --help ... so my previous question is not so important now (different outputs, different exit codes, one script handles this)
  • editor is always returning 0, with every possible (wrong) parameter,
  • I don't see --? documented anywhere

Summing up I am not so sure is it even worth considering to "fix by workaround inside script", because it will be:

  • quite heavy (e.g. echo $output | grep "Commandline Parameter:")
  • quite slow (e.g. save output to file > 'grep' ^ > display output)
  • will take quite many lines (separate conditions for every binary)

... so by now in my opinion enough is that what we have now, namely exceptions for official -h & --help and in the script area we have ~ stage wontfix

filux avatar Jan 29 '16 19:01 filux

I think a simple ldd and grep would help: ldd <binary> |grep "not found"

So no need to do anything depending on the exitcode of the binary. ( this should really be fixed as it is pretty annoying so I removed the "won't fix" label)

titiger avatar Jan 31 '16 00:01 titiger

nope, by this you will kill debug for situations where script itself found library but incompatible

e.g. as you reported recently situation with 'wx2.8 & missing wx3.0', after proposed by you changes in this situation we don't have any "not found" so debug (in probably hardest to investigate cases) is killed > imo unacceptable :D ... also don't forget about libraries in the 'lib' directory because they also remove "not found" status and also may be incompatible with something

... besides this who cares so much what output will someone get in situation when he used wrong parameter, if someone is using parameters (with --help exception) then it has to mean he is a "advanced user and know what he is doing" so should use correct parameters or should understand the current output and we are talking about maybe 5% users, seriously I don't see any reason to make script much more heavy for 100% users or kill useful debug to satisfy maybe 2% (because not all of them will use wrong parameter ever)

this fix should be really started as fix inside MG (also because there already exist method of detection for this situation [because you see list of all parameters]), just make a unique exit code for "wrong parameter" (perfect situation will be when every MG's binary will use same unique exit code for this situation) ... and then just few additional characters inside script, in 'lightweight' condition will do the rest

filux avatar Jan 31 '16 08:01 filux