`ct record -o` has unexpected behavior

[tzanko-matev]

The following work:

ct record ./path_to_noir --output-folder=path_to_trace
ct record ./path_to_noir -o=path_to_trace
ct record -o=path_to_trace ./path_to_noir
ct record --output-folder=path_to_trace ./path_to_noir

But the following doesn't:

ct record -o ./traceee examples/noir_simple_sha/
[error]: Unhandled exception
[error]: codetracer.nim:18        codetracer
launch.nim:125           runInitial
record.nim:39            record
language_detection.nim:54 detectLang
fatal.nim:54             sysFatal

ct record examples/noir_simple_sha/ -o ./traceee
@["examples/noir_simple_sha/", "./traceee"]
1
codetracer: starting language tracer with:
/home/tzanko/code/repos/codetracer/src/build-debug/bin/nargo trace --trace-dir /home/tzanko/.local/share/codetracer/trace-17/ ./traceee
error: unexpected argument './traceee' found

Usage: nargo trace [OPTIONS] --trace-dir <TRACE_DIR>

This doesn't conform to the usual way arguments are passed. -o ./trace should work especially when it is before the path of the Noir program. It also might be a problem that we are parsing program arguments which are written after the program path. This doesn't conform to argument format in the help message:

ct record --help
CodeTracer - the user-friendly time-travelling debugger

Usage: 

codetracer_depending_on_env_vars_in_tup record [OPTIONS]... <recordProgram> <recordArgs>

 <recordProgram>           Program to record.
 <recordArgs>              Arguments for record [=@[]].
                          longer description for record.

The following options are available:

     --lang               Language of the recording. Supported languages: c, cpp, rust, ruby, python, lua,
                          nim ???.
 -o, --output-folder      Output folder for the recording [=.].
     --backend            Record backend.
 -e, --export             Export zip file for the recording.
 -t, --stylus-trace       Path to a stylus emv trace json file.

[alehander92]

yes, our nim-confutils fork doesn't currently parse command parameters this way(-o <parameter>) for now: there was a reason this wasn't trivial to support, we have to try to remember it and write it down here

[alehander92]

(sorry, linked to it in a commit/PR by mistake, haven't tried to fix this for now, no plan for it yet)