WIP Expand input and output functionality #9
Loading…
Reference in New Issue
No description provided.
Delete Branch "input_output"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This is a draft of intended functionality that expands what input and output options are available. These are inspired by pandoc, awk and sed.
This originally came from the suggested feature of being able to save output to a chosen file.
The main changes are:
For full detail, refer to the Documentation section of README.md, but feel free to provide any feedback or questions!
WOW. You are bringing it with the good ideas. I was using gfu last night to make a gopher version of the bombadillo site (
gopher://bombadillo.colorfield.space) ... and at one point I thought: "It would be nice to just type stuff in and have it convert and go to file in real time". As such, I love this idea! Would it append to the given output file every time you hit enter/newline? How would you exit writing mode? A period on its own line? Or just ctrl-c? I like the default behavior being stdout and stdin and using flags and options to do other things.In-place is really solid and output just makes sense. This all seems great! I am also a fan of the short syntax (
-o -ietc).I actually was not thinking about stdin in that fashion, more piped text from other applications or files, and haven't used it myself before. It's something to learn about though, and initial reading is very interesting. Let me see what I can do!
Thanks for the feedback!
And the page looks great!
I would think that accepting stdin would allow for some level of typed input from a user, but ending it is the tricky part (it, of course, allows for input from a pipe, which would likely be the more common use case).
gfu is really turning into a more full featured cool tool than I had imagined :) This is awesome!
I just wrote this last night (to be expanded upon):
https://tildegit.org/sloum/mapcheck
I wanted to write something in awk as a learning exercise so I wrote a gophermap validator. It just gives messaging now, but I plan on moving it into a script file so that it can take options and I think my plan is to make it so the output of gfu can be piped into it and it can report out to standard error any issues and write to a given file with a -o option. Not sure yet. Try it out in its current state with any old gophermap (you may need to mangle it a bit to get errors) it just takes a file or few as argument(s).
That is pretty cool, it works pretty well. It could easily take output from gfu, and advise on any broken links or other errors. I'll have to add it to the examples for gfu redirection.
I've implemented the functionality as a first go, there are some points I'll mark for review.
This is functionally complete now, with hopefully clearer code.
Testing has only been simple manual checking. I would really like an automatic way run the program with some defined input and output, to confirm it is correct. An example might be:
assertEqual((gfu -v), ("gfu - gopher format utility%"))
where the input is that gfu is run with the -v flag, and the output checked is the start of the version output information.
This can be done externally using the makefile or a bash script, but it is a bit of a steep learning curve. I'm not too sure what other approaches there might be.
I wonder if there is a mocking library for golang. A quick look turned up this: https://github.com/golang/mock
Does that seem helpful toward that end?
I'm actually not sure.
It seems like a choice between:
'main()using mocking or whatever is required.main()for unit testing.I'm leaning towards the third choice, for the following reasons:
It will take some time to investigate and build any of these options, but it is worth the time to learn. I don't want that to get in the way of this going forward though, so I'll merge this in and complete the testing later.
Interesting. I would tend to lean toward #2, but that may be that unit testing of all of the tests that are done for code makes the most sense to me and seems the most straightforward. You definitely seem to have more experience with testing, and so I defer to your expertise. But definitely keep posting comments or updates about it, as I tend to learn a lot more about that process from your PRs. :)