fop(1) and Rust sysexits support (no yacexits!) #18
No reviewers
trinity
Labels
No Label
bug
duplicate
enhancement
help wanted
invalid
joke
question
wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: bonsai/coreutils#18
Loading…
Reference in New Issue
No description provided.
Delete Branch "fop"
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?
The code probably runs (I haven't tested compiling yet) but I hope you heed my suggestions.
@ -59,1 +61,4 @@sysexits: build_dir# bandage solution until bindgen(1) gets stdin supportprintf '#define EXIT_FAILURE 1\n' | cat - include/sysexits.h \Why define EXIT_FAILURE here? It's already in the C standard library. Unless this is for Rust purposes specifically.
This is for Rust only :)
@ -60,0 +64,4 @@printf '#define EXIT_FAILURE 1\n' | cat - include/sysexits.h \> build/include/sysexits.hbindgen --default-macro-constant-type signed --use-core \"$$(printf '#include <sysexits.h>\n' \Why
$$here? I can't quite follow.$$escapes the$so that make doesnt try to resolve the subshell as a variable@ -60,0 +65,4 @@> build/include/sysexits.hbindgen --default-macro-constant-type signed --use-core \"$$(printf '#include <sysexits.h>\n' \| cpp -M -idirafter "$$PWD/build/include" - \Can cpp not take a relative path? It can be safely assumed that a Makefile is executed with PWD being the Makefile's parent directory. Why pass
$PWD/pathliterally versus the path itself with the shell doing the variable expansion?it can, but i think i had a reason in a prior solution not to use the relative path because it causes side effects. i will look back into it
@ -60,0 +66,4 @@bindgen --default-macro-constant-type signed --use-core \"$$(printf '#include <sysexits.h>\n' \| cpp -M -idirafter "$$PWD/build/include" - \| sed 's/ /\n/g' | grep sysexits.h)" \It would be nice to have a further level of indent to indicate the pipeline within the
"$()". I have a hard time reading this.Multiple pipeline statements on the same line also make this a little tricky for me.
@ -0,0 +38,4 @@})},None => {eprintln!("{}", usage);It would be better to check that there are enough arguments before anything else to avoid unnecessary operations.
@ -0,0 +45,4 @@let mut buf = String::new();stdin().read_line(&mut buf).unwrap();let mut fields = buf.split('␞').collect::<Vec<&str>>();Perhaps we should have a defines.h to set magic numbers like the ASCII record separator as the delimiter.
I think it would be better to have ASCII horizontal tabs as the delimiter if standard output is a tty so output is readable in all fonts and on all terminals. At least npc(1) exists.
I tried this, but for an unknown reason bindgen will not output Rust bindings to the variable set in the header file. I will investigate further
I’m going to write a library in Rust (with C bindings) which handles ASV stuff.
@ -0,0 +29,4 @@let argv = args().collect::<Vec<String>>();argv.get(2).unwrap_or_else(|| {eprintln!("Usage: {} index command [args...]", argv[0]);It would be nice to be able to narrow down fields.
That way if data looks like
A [US] B [RS] C [US] D [GS] E [FS]you can do
fop -f 1 -g 1 -r 2 -u 2 sed 's/D/F/and getA [US] B [RS] C [US] F [GS] E [FS]. The same could be accomplished simpler but the point is to allow fine-grained control within ASV structures.I’m not exactly sure what the best way to go about this would be. I didn’t see this before adding the
-doption.I suppose we need to resolve #19 before we can truly decide on what to do.
After going over this with Trinity verbally, we have decided to merge the existing fop(1) implementation while we work on resolving #19.
WIP: fop(1) and Rust sysexits support (no yacexits!)to fop(1) and Rust sysexits support (no yacexits!)Pull request closed