When looking for wherever a program or a filename appears in the system, a short scrip is "findinner" which another script calls with a long parameter list consisting of path names ending with ".sh" or ".menu". "findinner" looks like this:
Is there a way to not have to modify "findinner" every time it is used? I would prefer to leave the scripts alone and just provide the search term as a parameter.
I have created symbolic links to several frequently used commands, for example:
"lt" is a link to "ls -ltrgo|tail". What can I do to make these links available system-wide, or at least in the directories my coworkers are in most of the time? I have copied the link to several directories, and... (6 Replies)
Hi, I have a task to search for a file called 'Xstartup' in the whole system because there might be different versions of it which overrite eachother.
Can anyone suggest a smart command to run this search ? The machine needs to scan every single folder beginning from root.
Please help, I am... (5 Replies)
Hello,
I am new to shell scripting and I was trying to write a script that would force a system wide password change except for admins. I am having some trouble and any help that someone could give me would be greatly appreciated. I am trying to do it by using the UID as the marker for anyone... (6 Replies)
Hi all,
Is there any system wide limit on number of user threads. I only find nkthread as a tunable parameter,apart from the `per process limit`. (1 Reply)
Hi,
I need to look for a config file (ldap.conf) and pick the latest modified file.
`locate` tells me there are many ldap.conf's, some in /etc, /usr, /home, etc.
Is there some way I can sort them by last modified time via bash?
I was thinking maybe I could pipe the output of `locate` to `ls... (4 Replies)
Dear Fellows;
As being new to linux, i have tried to synamically load a custom library which overrides some system calls like conncet(), socket() etc.... for custom purposes.
It works well, if declaring the environment path LD_PRELOAD and execution of the application to be override... (0 Replies)
We need to have many of our users all send encrypted files to a single FTP server. The problem, if I understand how encryption/decryption works (which I don't), is that each user would normally have their own private and public key. The other end needs to be able to decrypt the file(s) using a... (6 Replies)
I have downloaded and installed a library called htslib for specific bioinformatic use but not for the system (I'm using Ubuntu 18.04). Only parts of the library is needed for my exercise to parse data in a type called VCF format (basically tab-delimited file but contains many information in... (14 Replies)
Discussion started by: yifangt
14 Replies
LEARN ABOUT DEBIAN
dh_installinit
DH_INSTALLINIT(1) Debhelper DH_INSTALLINIT(1)NAME
dh_installinit - install init scripts and/or upstart jobs into package build directories
SYNOPSIS
dh_installinit [debhelperoptions] [--name=name] [-n] [-R] [-r] [-d] [--params]
DESCRIPTION
dh_installinit is a debhelper program that is responsible for installing init scripts with associated defaults files, as well as upstart
job files into package build directories.
It also automatically generates the postinst and postrm and prerm commands needed to set up the symlinks in /etc/rc*.d/ to start and stop
the init scripts.
FILES
debian/package.init
If this exists, it is installed into etc/init.d/package in the package build directory.
debian/package.default
If this exists, it is installed into etc/default/package in the package build directory.
debian/package.upstart
If this exists, it is installed into etc/init/package.conf in the package build directory.
OPTIONS -n, --noscripts
Do not modify postinst/postrm/prerm scripts.
-o, --onlyscripts
Only modify postinst/postrm/prerm scripts, do not actually install any init script, default files, or upstart job. May be useful if the
init script or upstart job is shipped and/or installed by upstream in a way that doesn't make it easy to let dh_installinit find it.
-R, --restart-after-upgrade
Do not stop the init script until after the package upgrade has been completed. This is different than the default behavior, which
stops the script in the prerm, and starts it again in the postinst.
This can be useful for daemons that should not have a possibly long downtime during upgrade. But you should make sure that the daemon
will not get confused by the package being upgraded while it's running before using this option.
-r, --no-restart-on-upgrade
Do not stop init script on upgrade.
--no-start
Do not start the init script on install or upgrade, or stop it on removal. Only call update-rc.d. Useful for rcS scripts.
-d, --remove-d
Remove trailing d from the name of the package, and use the result for the filename the upstart job file is installed as in etc/init/ ,
and for the filename the init script is installed as in etc/init.d and the default file is installed as in etc/default/ . This may be
useful for daemons with names ending in d. (Note: this takes precedence over the --init-script parameter described below.)
-uparams --update-rcd-params=params
-- params
Pass params to update-rc.d(8). If not specified, defaults will be passed to update-rc.d(8).
--name=name
Install the init script (and default file) as well as upstart job file using the filename name instead of the default filename, which
is the package name. When this parameter is used, dh_installinit looks for and installs files named debian/package.name.init,
debian/package.name.default and debian/package.name.upstart instead of the usual debian/package.init, debian/package.default and
debian/package.upstart.
--init-script=scriptname
Use scriptname as the filename the init script is installed as in etc/init.d/ (and also use it as the filename for the defaults file,
if it is installed). If you use this parameter, dh_installinit will look to see if a file in the debian/ directory exists that looks
like package.scriptname and if so will install it as the init script in preference to the files it normally installs.
This parameter is deprecated, use the --name parameter instead. This parameter is incompatible with the use of upstart jobs.
--error-handler=function
Call the named shell function if running the init script fails. The function should be provided in the prerm and postinst scripts,
before the #DEBHELPER# token.
NOTES
Note that this command is not idempotent. dh_prep(1) should be called between invocations of this command. Otherwise, it may cause multiple
instances of the same text to be added to maintainer scripts.
SEE ALSO debhelper(7)
This program is a part of debhelper.
AUTHORS
Joey Hess <joeyh@debian.org>
Steve Langasek <steve.langasek@canonical.com>
9.20120909 2012-04-10 DH_INSTALLINIT(1)