I am writing a few custom man pages and I would like to include things that might change often such as the date of the man page's writing.
For example, one is in a git repo that I would like to update the man page's date whenever a change is made to it without having to do it by hand.
Is there a possibility to #include or call shell variables in the *roff file, or perhaps a markdown file and then use pandoc to "compile" the man page with?
I understand this is a strange question, but I haven't come across anything similar.
Please note this is different than simply including a man page in the $MANPATH to be called by man.
I.E., I want to use something like:
.TH foo 10 "$(git log -n1 | grep Date | tail -c 31)" "$(git branch | grep "*")"
in place of having to manually change the date and branch/head name every time. Whether this is in markdown and given to pandoc or something else or just in the roff file itself, I am okay with either.
Consider composing the content of the man page using a documentation generator language like asciidoc, which has most of the desired features. The asciidoc format can include external input files, and change all sorts of things on-the-fly as needed.
To include shell script, see Substitutions inside literals in Asciidoc
.
Or one could use a shell script to generate a config file, then include that file.
Apologies in advance if this answer is at present little vague, in that it's more of a software recommendation (without any actual code) than a real answer.
I see from your example line that you're using Git - I believe you can use a 'pre-commit' git hook (basically a script that runs before your commit is processed) to update the contents of the manpage (and stage the changes) on every commit.
For example, you could put the following commands in your .git/hooks/pre-commit file to update the contents of the manpage in place whenever you commit:
sed -i "" "s/^.TH foo 1 \".*/.TH foo 1 \"$(date)\"/" path/to/manpage.roff
git add path/to/manpage.roff
Note that the path is relative to the root of the git repository.
Related
I have a file.patch file generated from someone else. I want to review the patch file, but I would like to be able to apply my own git color config to the file.
I may not currently be in a git project directory and I may not even know what repo the patch file came from, but I just want to see basically context/additions/deletions colored with my normal git colors.
I'm looking for a pipeline solution rather than some external library. Something like:
git --please-color-this file.patch | less
colordiff < file.patch | less -R
The 'less' command is optional but I find it useful, e.g. for scrolling, searching.
less is not the program you're looking for, the colors are not stored in the file and less doesn't understand the diff format. Instead, use a tool that understands the diff format, for instance text editors such as vscode or vim. The best program is the program you currently use for merge conflicts.
I'm interested in simply adding a comment next to my files in Linux (Ubuntu). An example would be:
info user ... my_data.csv Raw data which was sent to me.
info user ... my_data_cleaned.csv Raw data with duplicates filtered.
info user ... my_data_top10.csv Cleaned data with only top 10 values selected for each ID.
So sort of the way you can comment commits in Git. I don't particularly care about searching on these tags, filtering them etc. Just seeings them when I list files in a directory. Bonus if the comments/tags follow the document around as I copy or move it.
Most filesystem types support extended attributes where you could store comments.
So for example to create a comment on "foo.file":
xattr -w user.comment "This is a comment" foo.file
The attributes can be copied/moved with the file just be aware that many utilities require special options to copy the extended attributes.
Then to list files with comments use a script or program that grabs the extended attribute. Here is a simple example to use as a starting point, it just lists the files in the current directory:
#!/bin/sh
ls -1 | while read -r FILE; do
comment=`xattr -p user.comment "$FILE" 2>/dev/null`
if [ -n "$comment" ]; then
echo "$FILE Comment: $comment"
else
echo "$FILE"
fi
done
The xattr command is really slow and poorly written (it doesn't even return error status) so I suggest something else if possible. Use setfattr and getfattr in a more complex script than what I have provided. Or maybe a custom ls command that is aware of the user.comment attribute.
This is a moderately serious challenge. Basically, you want to add attributes to files, keep the attributes when the file is copied or moved, and then modify ls to display the values of these attributes.
So, here's how I would attack the problem.
1) Store the information in a sqlLite database. You can probably get away with one table. The table should contain the complete path to the file, and your comment. I'd name the database something like ~/.dirinfo/dirinfo.db. I'd store it in a subfolder, because you may find later on that you need other information in this folder. It'd be nice to use inodes rather than pathnames, but they change too frequently. Still, you might be able to do something where you store both the inode and the pathname, and retrieve by pathname only if the retrieval by inode fails, in which case you'd then update the inode information.
2) write a bash script to create/read/update/delete the comment for a given file.
3) Write another bash function or script that works with ls. I wouldn't call it "ls" though, because you don't want to mess with all the command line options that are available to ls. You're going to be calling ls always as ls -1 in your script, possibly with some sort options, such as -t and/or -r. Anyway, your script will call ls -1 and loop through the output, displaying the file name, and the comment, which you'll look up using the script from 2). You may also want to add file size, but that's up to you.
4) write functions to replace mv and cp (and ln??). These would be wrapper functions that would update the information in your table, and then call the regular Unix versions of these commands, passing along any arguments received by the functions (i.e. "$#"). If you're really paranoid, you'd also do it for things like scp, which can be used (inefficiently) to copy files locally. Still, it's unlikely you'll catch all the possibilities. What if someone else does a mv on your file, who doesn't have the function you have? What if some script moves the file by calling /bin/mv? You can't easily get around these kinds of issues.
Or if you really wanted to get adventurous, you'd write some C/C++ code to do this. It'd be faster, and honestly not all that much more challenging, provided you understand fork() and exec(). I can't recall whether sqlite has a C API. I assume it does. You'd have to tangle with that, too, but since you only have one database, and one table, that shouldn't be too challenging.
You could do it in perl, too, but I'm not sure that it would be that much easier in perl, than in bash. Your actual code isn't that complex, and you're not likely to be doing any crazy regex stuff or string manipulations. There are just lots of small pieces to fit together.
Doing all of this is much more work than should be expected for a person answering a question here, but I've given you the overall design. Implementing it should be relatively easy if you follow the design above and can live with the constraints.
I created a small project using C to make some commands in Linux terminal.
I want to add a description to my project to call it when I use man command. Such as if my project name is hello.c, I want when I write command man hello.c to print the description I wrote for my project. Where do I write this description?
I saw this but don't know where or how I write the description.
There are several great tutorials for doing so:
How to write a man
page
Creating your own manpage
How to write a UNIX man page.
Pick one, and hack away.
If you feel that you are stuck somewhere, take a look at man pages from FreeBSD utilities like cat, echo, etc
Problem
I'm writing a set of scripts to help with automated batch job execution on a cluster.
The specific thing I have is a $OUTPUT_DIR, and an arbitrary $COMMAND.
I would like to execute the $COMMAND such that its output ends up in $OUTPUT_DIR.
For example, if COMMAND='cp ./foo ./bar; mv ./bar ./baz', I would like to run it such that the end result is equivalent to cp ./foo ./$OUTPUT_DIR/baz.
Ideally, the solution would look something like eval PWD="./$OUTPUT_DIR" $COMMAND, but that doesn't work.
Known solutions
[And their problems]
Editing $COMMAND: In most cases the command will be a script, or a compiled C or FORTRAN executable. Changing the internals of these isn't an option.
unionfs, aufs, etc.: While this is basically perfect, users running this won't have root, and causing thousands+ of arbitrary mounts seems like a questionable choice.
copying/ hard/soft links: This might be the solution I will have to use: some variety of actually duplicating the entire content of ./ into ./$OUTPUT_DIR
cd $OUTPUT_DIR; ../$COMMAND : Fails if $COMMAND ever reads files
pipes : only works if $COMMAND doesn't directly work with files; which it usually does
Is there another solution that I'm missing, or is this request actually impossible?
[EDIT:]Chosen Solution
I'm going to go with something where each object in the directory is symbolic-linked into the output directory, and the command is then run from there.
This has the downside of creating a lot of symbolic links, but it shouldn't be too bad.
You can't solve this without making some assumptions about the interface of $COMMAND. There is no single definition of what "output ends up in $OUTPUT_DIR" means. For one program this may be some files, but another program might just print something to stdout and yet another might try sending some data over the internet using some protocol or display something in a GUI and there isn't an obvious way of mapping all of these to "output goes to $OUTPUT_DIR".
So, you need to invent some assumptions and require any $COMMAND implementation to follow them. Then, it may get as simple as requesting that the command accept a parameter such as --target=<DIR>. If your command was some simple command, you would have to create a wrapper script around it to translate that parameter into what the app accepts. cp, mv and a few more utils already accept the parameter --target, so that may be a good starting point.
You cannot set the output directory, you can only set the working directory.
The problem is, once you set the working directory, other references are going to be invalid. For example in your code foo:
cp ./foo ./bar
If you have a specific command, there are workarounds (creating a script that alters arguments, prepending the directory to specific arguments), but in general this is not possible.
I would like to generate diffs for the sake of doing incremental backups of an sql database.
Using the standard unix 'diff' tool generates unnecessarily large files, since they include the full text of deleted lines. I only need support to be able to patch in one direction (to generate the current db dump from the full dump and an incremental patch).
How would I go about doing this? I have tried so far using diff -e and patch -e, but it doesn't seem to be working correctly, as the resulting file is corrupt (possibly an issue with the 'ed' tool used in cygwin)
back in the old days, before Vim, there used to be a line-oriented UNIX editor called 'ed' ..
diff has an option built in ( -e option ) , with which you can create an edit script from the diff.
Check here: and look for the section "Edit Script"
http://en.wikipedia.org/wiki/Diff
http://docs.freebsd.org/info/diff/diff.info.ed_Scripts.html
here's an example:
http://www.araxis.com/merge/topic_diff_report_editscript.html
another way to do this is to create a patch file (see 'man patch')