I've made a small script in my machine, and an alias in .bashrc that calls it. It's a bash script with 3 lines, but it can grow.
Now, some people in my team found it useful, and want to use it.
Instead of saying "copy this alias, do this, do that, install that lib" I was thinking about creating a simple package to be a little more professional. Fact is, I've never done something like this before. And the problem to me is not creating a package, is trying to decide what usually do you put in a package.
Suppose I want to take my script, and create myapplication. I want to create a .deb file that my team would install and:
Have a /usr/bin/myapplication or /usr/sbin/myapplication (what's the difference between them?), so they would just call myapplication at their terminal and it would work;
Have a man page; (Where are usually located man pages in a debian system?);
Have a possibility to read a .myapplicationrc in home folder with some configurations;
Have an entry for shortcuts in a gnome installation (is it possible to have an universal shortcut "format" that's is available to KDE and Gnome as well?);
Install dependencies.
I'm new to all that stuff. I usually code simple scripts and create an alias in my bashrc. I've never done a package before. Which guides do you know of that can help me accomplish what I thinking of above?
Here is a place to start, though I welcome a more succinct answer.
I couldn't find a complete guide. I think the best thing to do is download a package that does exactly what I'm thinking of and do some reading, like taskwarrior.
Related
On my PC I have quite a few aliases, path variables and modules like npm, scoop shims, go modules, powershell/bash functions/modules and my question is, does the pc search through all of these things the moment after I run a command? or is there some kind of registry that stores all of these values so they are quickly accessible? That would be my guess but both on my linux machine and my windows pc I have syntax highlighting on and it "knows" that a command is valid even prior to running it.
I was really curious about what process is taking place here earlier today when I installed gum (charmbracelets go TUI module) and it automatically recognized "gum -file" as a valid command when I hadn't explicitly defined it anywhere and it isn't prepended with "go" or "scoop" (assuming that I used one or the other to install the module)
I tried googling this question but I was inundated with pages of irrelevant stuff regarding basic questions about path errors and bloated articles about how to add stuff to your path.
It's just one of those days...
I want to create a shell script (naive version could be a simple alias), but I want to make it the good way from the bottom up. Writing script itself isn't a problem at all, but since it's possible a couple of other people would like to use this script as well I want to make it accessible and maintainable as well. That's why I have two questions:
Are there any guides regarding structure of the repository with shell script inside? I mean, some conventions that, for example, we put a script in some directory, manpage, should I split it into multiple files etc.
How to make this script be accessible to other people? I know that if we want to install command line tool, we move it to /usr/bin or /usr/local/bin, but what with docs or some dependencies?
There are a lot of tutorials regarding writing command line tools in Ruby or Python with some templates how to manage everything, but I haven't found anything about writing a command line tool as a shell script.
In general, you would follow the conventions in man hier for the distribution. A shell script would be treated the same as a binary file.
I saw that there is a lua plugin for eclipse and there is a docpage on the awesome main page api_doc and all the .lua files in /usr/share/awesome/lib.
So I thought it must be possible to create a Library or Execution Environment so that one has tabcompletion and docview.
So I tried making my own Execution Environment:
wrote the standard .rockspec file
downloaded the documentation made an ofline version of it and put it in docs/ folder
ziped the files and folders in /usr/share/awesome/lib
ziped all up
tried it out ... and it failed.
When I try to view a documentaion for a .lua file I get "Note: This element has no attached documentation."
Questions: Am I totaly wrong in my doing (because I have the feeling I am)? Is there any way to edit the rc.lua with tabcompletion and docview?
Koneki will probably take a while to setup, but it's definitly worth it. Going for the".doclua"(by using version 1.2) would certainly make it, but I doubt that using a script to generate the information you need, would work out on the long run.
Most likely, you'll probably pass a bit of time to define what kind of object you're dealing with every time you come across one. The right to do, would be to actually take the time to see if the object/module/inner type inherit from an another object, so can actually have more completion feature as you keep using autocomplete to go from one object to another by pressing "dot"+ctrl_space.
In an ideal world, one person could probably make it right and share to other, so they can enjoy a full featured autocomplete editor.
Found solution for eclipse.
First off the idea of setting up an Execution environment was the wrong one.
So the whole thing about downloading the doc although.
For more information on that visit eclipse Wiki for LUA Development Tool.
The right thing to do is to add a source folder which contains the /usr/share/awesome/lib directory.
The bad news is that my comment from above was totally right, which means one has to configure each .lib file in /usr/share/awesome/lib to meet the requirements of the Documentation Language described here.
Than editing the rc.lua (which one can add to the project in eclipse) works with tabcompletion and doc view.
Since the Documentation Language used in the lib files is similar to the one used by "LUA Development Tool" one has not to change many things. Maybe there are even scripts for that.
I often find myself taking a lot of time to navigate through my filesystem when using the linux shell. This generally occurs because the autocompletion of bash only works if you provide the start of the file/dirname. What I often end up in is a lot of 'ls' with 'grep' commands, finally doing a 'cd'.
When you use a GUI based filebrowser (like Nautilus) you can type any part of a file/dirname and it will have matches that it jumps to directly. This makes it a lot easier and faster to navigate.
I wonder if anybody knows any great tools that helps with this problem. I know of the existence of Midnight Commander, though I never really used it for real and I couldn't figure out a direct solution for my problem the first couple of times I tried it. Also it seems not suitable because I want to have my shell's current working directory to be changed so I can do stuff there, instead of being stuck in an external program like Midnight Commander.
Try autojmp
https://github.com/joelthelion/autojump
And following article provides another solution
http://jeroenjanssens.com/2013/08/16/quickly-navigate-your-filesystem-from-the-command-line.html
You can first use the autocd or autopushd in zsh. You would just have to type the directory you want to go to, without the hassle of typing cd or pushd everytime.
You also have the globing possibility. For example, if I got those file in a directory:
1-a.tar
1-b.tar
c.tar
I can just type
*a.tar
without caring about the beginning of the file.
As a last solution you can always use an alias to the find command with a personalized option.
I am trying to figure out which files were changed when I run an app install via make install. I can look at the script, but that calls other scripts and may or may not touch other files, etc. How can I do this programmatically?
Implementation: http://asic-linux.com.mx/~izto/checkinstall/
Several ways come to mind. First, use some sort of LD_PRELOAD to track all files opened. Second approach, compare filesystem before and after.
If your kernel supports it, you can use inotify (a handy interface is inotify tools) and watch your home directory, if the package was configured with --prefix=/home/myusername
I've noticed that checkinstall (using installwatch via LD_PRELOAD) does not always catch everything, the last time I used it it did not catch empty directories that were created for spooling, which caused the subsequent generated .deb's to break.
Note, don't use inotify if you are installing to /, in that case you have to use installwatch or just read all of the makefiles / install scripts closely.