To shell or not to shell ?

[roadelou]

This is more of an architectural decision than a code issue, but I think it is important to bring it up regardless. What is at stake here is that the application you wrote is behaving kind of like a shell, but only implements a subset of a shell capabilities.

This brings several issues :

• A lot of commands are not available in you shell, for instance you did not write a 'ls' command so I cannot see the content of a folder before sorting it. In fact, no tool from the outside is available within the shell.
• Some cool features that are built into shells are not available here (up arrow to use last command, tab to autocomplete etc...).
• For a third party, it is not possible to extend what the tool does (because you cannot add a new command without changing the source code).
• It is not easy to interface your tool with other existing tools, you would have to feed it its command with echo for instance.
• There is no programming language within your shell, therefore you cannot 'script' with it.

The risk with this approach is that you might end up in some kind of an uncanny valley, where your tool is doing its own thing so it is hard to use it within other tools, but at the same time it is not flexible enough to stand on its own, and therefore you still need to go back to the shell when you are working.

To solve this issue, I would advise you to go one of the two ways : either make this tool a CLI thing that can be integrated within the existing shell, or make it an entirely independent shell.

The CLI way

Turning your project into a very convenient CLI tool should not be very difficult, in fact you would only need a few things (not necessarily all at once !)

Make it a python package

By turning your tool into a python package, you can set its "entry point". For instance, when you install the black code formatter in python, it will create a short script (called 'black') that calls the right function within the black library. You can then use it very conveniently from your shell.

Use argv and not just input

The command line arguments are received from argv and not from stdin. If you were to process argv and then switch to stdin it would let people use you code as (for instance) :

video-logging folder
video-logging trash 60
video-logging date
video-logging help

Follow GNU style CLI guidelines

A lot of Windows command line tools use the dos style CLI (I thing it comes from dos) :

# On windows, using cmd.exe
dir /s/w/o/p/a:-d

But that is not the one we are used to, and most tools use the GNU style format derived from getopt :

ls -a -F

For commands that are actually a proxy to other commands, (as is your case), one can use a 'git-style' CLI :

# Not how "-v" behaves the same way for commit and push
git commit -v -a -m "Commit message"
git push -v

It is not recommended that you try to parse the GNU style command line yourself, instead you could use something like argparse in python. This way, one could use your tool as (for example) :

# To sort the video files (-e for --extension)
video-logging folder -e Videos
# -t for --time for instance
video-logging trash -t 60
video-logging --help
video-logging date --help

Just to be clear, this would mean that you have to use argparse once for the global video-logging tool and once for every sub tool (folder, trash etc...) if you follow this example.

By the way, it is advised to let the user to set the verbosity level of a tool from the command line with flags such as :

video-logging -v folder
video-logging --silent trash -t 60
# Or if you are on the quiet team
video-logging --quiet date

Don't give up on the nice interactive user interface

One simple way to keep the interface of video-logging (which is quite nice by the way ❤️) is to take advantage of the symmetry between argv and stdin (if you decide to implement it).

That would require a bit of fiddling with argparse, but it clearly able to handle it, you just have to tell it to stop parsing at the first non recognized argument. That may very well be the default behavior of argparse by the way.

You could for instance decide that the user interface will start if video-logging is called without a sub program name :

# This one would start the interaction
video-logging
# This one would also start the interaction
video-logging --verbose
# This one is debatable, it depends on your interpretation
video-logging -s # -s for --silent

This way your project can be fully taken advantage of as a CLI tool in scripts, but a human user could also use the nice interface.

Note that the CLI I presented is just an example, there are countless other ways to do this, just find one that you are comfortable with.

The shell way

Before I go any further, I have to emphasis that this would take a significant amount of work ⌛ and I am not completely sure how this would concretely be achieved.

The main issue when writing a shell is that it must not only support a lot of built-in utilities (like cd, the pipe '|', redirection '>' etc...), but it also has to embed an entire programming language to be usable in real world scenarios. As you already know, writing a programming language is very hard on its own, but writing one for the command line holds an additional complexity.

Indeed, a shell language must not only support standard language constructs :

# That is a function in bash, other shell can have different a syntax
function hello_world {
  message="Hello, World!"
  echo $message
  return $message
}

But it must also support one liners that are commonly used :

grep "Hello, World!" ~/ISSUE.md | grep -v $EXCLUDE > hello_world.txt

The syntax of the shell language must be able to make sense of both code snippets, which leads to non-trivial (as in extremely complex) syntaxes.

I guess that this warning should be enough to push you toward the first decision 😉 (if you ever considered the second one), but in case it did not I will try to share some hints on how that could be achieved.

Fortunately, you might not even have to write the shell syntax yourself. There are already a lot of usable implementations out there. I believe that the most common embedded shell-like interpreter is TCL.

The way this would work is through extensions. TCL for instance allows you to extend its core with extensions written in some language (I will blindly guess C/C++). Writing such extensions probably is fairly challenging, but I have never done it myself so don't take my word for it.

On the bright side, you now (or in a month of work to be fair 😄) have a fully functional shell that has some nice video handling abilities. However, you had to rewrite all of your code to C/C++/something else, which might not be what you were looking for.

Conclusion

To sum things up :

• If you are just trying to create a tool to perform various video-related manipulations, you probably could tweak your implementation to make it fit nicely in the CLI world.
• If you are looking to build a fully fledged shell, I would advise that you first find a preexisting shell, and then extend it to perform video manipulations.

The choice is yours, and it only depends on what you want to do with your project (and how much time you have ahead of you 😆). I would however like to emphasize that making no choice here would probably be worse than any of the two paths I described 😄

---

EDIT: After verification, I was wrong about git-style CLI, I changed the issue to the correct version 😉