argv/argc docs needed

[eyberg]

not really sure what to say here but tijoy pointed out that some binaries expect the binary name as the first argument and some don't - I noticed this with both nginx && apache when I was trying to load them

for instance w/apache you'll see this ->

open /lib/x86_64-linux-gnu/libapr-1.so.0 - not found
open /etc/gai.conf - not found
httpd: Could not open configuration file /httpd.conf: Function not implemented
exit_groupexit status 1
eyberg@dungeon:~/ap$ ops run -p8083 -f -c config.json httpd^C
eyberg@dungeon:~/ap$ cat config.json
{
    "Files":["httpd.conf"],
    "Dirs": ["usr", "dev", "etc", "build", "logs"],
    "Args":["httpd -f", "/httpd.conf", "-DFOREGROUND"]
}

that error msg is actually a diff. error mgs it's finding it here but if we leave out the "httpd" part instead of finding the file it'll print this msg instead ->

open /lib/x86_64-linux-gnu/libapr-1.so.0 - not found
Usage: -f [-D name] [-d directory] [-f file]
          [-C "directive"] [-c "directive"]
          [-k start|restart|graceful|graceful-stop|stop]
          [-v] [-V] [-h] [-l] [-L] [-t] [-T] [-S] [-X]
Options:
  -D name            : define a name for use in <IfDefine name> directives
  -d directory       : specify an alternate initial ServerRoot
  -f file            : specify an alternate ServerConfigFile
  -C "directive"     : process directive before reading config files
  -c "directive"     : process directive after reading config files
  -e level           : show startup errors of level (see LogLevel)
  -E file            : log startup errors to file
  -v                 : show version number
  -V                 : show compile settings
  -h                 : list available command line options (this page)
  -l                 : list compiled in modules
  -L                 : list available configuration directives
  -t -D DUMP_VHOSTS  : show parsed vhost settings
  -t -D DUMP_RUN_CFG : show parsed run settings
  -S                 : a synonym for -t -D DUMP_VHOSTS -D DUMP_RUN_CFG
  -t -D DUMP_MODULES : show all loaded modules
  -M                 : a synonym for -t -D DUMP_MODULES
  -t -D DUMP_INCLUDES: show all included configuration files
  -t                 : run syntax check for config files
  -T                 : start without DocumentRoot(s) check
  -X                 : debug mode (only one worker, do not detach)
exit_groupexit status 1

we should prob. think about documenting this on the "run your own binary" as a faq or something until we drill more into it

[cbarraford]

@eyberg why the inconsistency? Should the action item to be consistent rather than documenting a possible unnecessary complexity??

[eyberg]

i think this needs more discussion as both behaviors are potentially correct

[tijoytom-zz]

This is mostly a C convention that argv[0] is the name of the executable and many program expect it that way. For example golang argv[0] is the program name and any kind of arg parsing code will do something like this firstArg = os.Args[1] expecting os.Args[0] to be program name. We can change our elf_entry point invoke to always pass in the additional argument[0] with program name

[eliasnaur]

Without argv[0] filled out, just importing the standard Go package flag panics on init:

$ cat flags.go 
package main

import _ "flag"

func main() {
}
$ go build flags.go && ./ops run flags
Finding dependent shared libs
booting /home/elias/.ops/images/flags.img ...
assigned: 10.0.2.15
panic: runtime error: index out of range [0] with length 0

goroutine 1 [running]:
flag.init()
	/home/elias/dev/go-tip/src/flag/flag.go:1007 +0x176
exit status 5

[eyberg]

until this is resolved one thing you can do now to get by this is explicitly setting the first arg ->

➜  t  cat config.json
{
  "Args": ["flags"]
}

➜  t  ops run -c config.json flags

it's unclear to me whether this is strictly an ops issue or something that needs to be fixed in the manifest for nanos ingest, it's also unclear to me why this behavior exists to begin with - I believe it's leftover cruft from the load/run of ops

[eyberg]

talked this over and the consensus is that this is an ops issue that should be fixed in ops

So basically, ops doesn't default to placing the program name as the first argument. I think that should be default; program name as argv[0] and any specified arguments start at argv[1]...

But we can also have nanos just stick the program name in argv[0] if no arguments are specified as a little insurance (or if someone is manually rolling a manifest and leaves args out - seems like a reasonable default)

[eyberg]

fyi - there's a small chance that we might need to re-roll some pkgs &&|| fix some https://github.com/nanovms/ops-examples - but can do that as an addendum once a fix here is in place

[eyberg]

old/closing - nanos will now fill in the program name if null arguments coming from ops