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/path literally versus the path itself with the shell doing the variable expansion?
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/path` literally versus the path itself with the shell doing the variable expansion?
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 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.
Perhaps we should have a defines.h to set magic numbers like the ASCII record separator as the delimiter.
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
> Perhaps we should have a defines.h to set magic numbers like the ASCII record separator as the delimiter.
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
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 get A [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.
It would be nice to be able to narrow down fields.
```
Usage: fop (-f [file field]) (-g [group field]) (-r [record field]) (-u [unit field]) command arguments...
```
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 get `A [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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
trinity
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.
Pull request closed