06-08-2011
There's two things to consider, whether they'll find it and whether they're actually allowed to use it.
The PATH variable is what a users' shell will use to locate programs. /usr/bin will very probably be in the default PATH so users will find things in there by default. If they need to look in /usr/local/bin/ you may need to add that to the PATH. The PATH is adjusted in a variety of locations, see
How does the default PATH get set on RHEL?
Even if it's not in their PATH, they can still run programs by giving the full path themselves, i.e. running /usr/local/sbin/myprogramname
File permissions can also be used to allow or deny users from running programs they'd otherwise be able to access, but without knowing what you're trying to do this may be getting into too much detail.
10 More Discussions You Might Find Interesting
1. Solaris
I have a script in my home direcroty which upon execution gives the essential system information like memory,cpu etc and is currently owned by root:root. Now I want to see that every non root user will run this file and grab the reqired system info. I know this is some thing associated with chown... (2 Replies)
Discussion started by: chrs0302
2 Replies
2. Shell Programming and Scripting
hi i need to make a script that will check the directories of the users on mp3 or mp4 files. if so they must be automaticly deleted and they have to get a warning message instead.
this should be running every day at 1 pm and should be done within the cron file.
could someone help me with... (2 Replies)
Discussion started by: stefan
2 Replies
3. Solaris
I attached a README file that I will refer to.
I successfully completed everything in the README file until step 4.
# pwd
/gani/gani-2.4.4
# ls
COPYING Makefile.macros gem.c
Makefile Makefile.sparc_gcc gem.h
Makefile.amd64_gcc ... (1 Reply)
Discussion started by: Bradj47
1 Replies
4. UNIX for Dummies Questions & Answers
Are the programs written on schedulers ,thread library , process management, memory management, et al called systems programs ? How are they different from the programs that implement functions like open() , printf() , scanf() , read() .. they have a prefix sys_open, sys_close, sys_read etc , right... (1 Reply)
Discussion started by: vishwamitra
1 Replies
5. Solaris
Hi All,
How to restrict the NIS users not to change their passwords in for NIS users??
and my NIS user is unable to login to at client location what could be the problem for this ?
Any body can help me. Thanks in advance. (1 Reply)
Discussion started by: Sharath Kumar
1 Replies
6. Shell Programming and Scripting
hi,
i am new to shell scripts
i write a shell script to create multiple users but i need to give passwords to that users while creating users, command to write this script (1 Reply)
Discussion started by: DONFOX
1 Replies
7. UNIX and Linux Applications
Is it possible to use {SHA} with ldappasswd? I didn't find responsible option in manual page and doc (1 Reply)
Discussion started by: urello
1 Replies
8. UNIX for Dummies Questions & Answers
Edit: Sorry. Mistakenly posted - please delete (3 Replies)
Discussion started by: Reddax
3 Replies
9. OS X (Apple)
As you may already know, Apple has integrated all the GNU developer tools into their own graphical development environment so you can no longer use them from the command line. This means that open source software that is distributed as source is inaccessible to users of newer versions of Mac OS X,... (4 Replies)
Discussion started by: Ultrix
4 Replies
10. UNIX for Dummies Questions & Answers
Hey guys,
Suppose i run passwd via bash shell. It is a suid program, which temporarily runs as root(owner) and modifies the user entries.
However, when i write a C file and give 4755 permission and root ownership to the 'a.out' file , it doesn't run as root in bash shell. I verified this by... (2 Replies)
Discussion started by: syncmaster
2 Replies
LEARN ABOUT DEBIAN
envpath
ENVPATH(1p) User Contributed Perl Documentation ENVPATH(1p)
NAME
envpath - Advanced operations on path variables
SYNOPSIS
Run this script with the "-help" option for usage details.
DESCRIPTION
Parses the command line, modifies the specified path variable(s), and execs the remaining arguments. There are two modes, simple and
advanced:
SIMPLE MODE
Simple mode presents an alternative, platform-independent syntax for specifying paths wherein the path separator is "," and environment
variables can be expanded with @NAME@. For example
envpath PATH=@PATH@,/usr/ucb -- printenv PATH
appends "/usr/ucb" to $PATH and execs printenv PATH. The "--" is optional.
You can also specify prepending or appending by using "+=" or "=+" respectively:
# place /usr/ucb at the front
envpath PATH+=/usr/ucb -- printenv PATH
# place /usr/ucb at the back
envpath PATH=+/usr/ucb -- printenv PATH
Simple mode requires only this script; it does not require Env::Path to be installed.
ADVANCED MODE
Advanced mode basically provides command-line access to the features of Env::Path (see), which must be installed. The "-E" flag selects the
path variable to operate on and other flags specify operations on it. E.g.
envpath -E MANPATH -A /tmp -R /usr/share/man -N -U -- man ...
would take MANPATH, append /tmp to it, remove any references to "/usr/share/man", remove any dirs which don't exist ("-N") and remove
redundant entries ("-U") before running man.
The -Whence option allows patterns. Thus
envpath -W "cat*"
would find all programs on PATH which match cat*.
CLEARCASE WINKINS
A big part of the motivation for this script was for use with ClearCase builds; iff you know or care about ClearCase read on. Typically,
during builds (and not just with ClearCase), pathvars such as PATH, CLASSPATH, and LD_LIBRARY_PATH must be strictly controlled. One choice
is to force static values of these into the environment during the build process, another is to simply require/expect users to set their
paths appropriately. Each of these can lead to subtle build or runtime errors, however, and makes it hard for new users to get up to speed
since their personal environment must be just so.
Another common choice is to use only full pathnames within the Makefile, avoiding reliance on search paths at all. This is often the best
way to go but can suppress ClearCase winkins. For example, say you're generating ascii files of some type with a binary executable you
just built:
$(INCDIR)/foo.h: $(BINDIR)/foomaker $(BINDIR)/foomaker ...
The problem with this is that $(BINDIR) likely contains a platform part such as 'solaris' or 'hpux', which makes it impossible to wink in
the foo.h file on other platforms even though it's ascii. This same thing could come up even with a standard pre-built utility that's in
different places on different platforms; "yacc", for instance, is in /usr/bin on Linux and /usr/ccs/bin on Solaris.
You could modify the path on the fly:
$(INCDIR)/foo.h: $(BINDIR)/foomaker PATH=$(BINDIR)$(SEP)$$PATH foomaker ...
but this suffers from the same problem: since $(BINDIR) and $PATH are expanded literally within the build script they'll suppress winkins.
Here's a solution using envpath:
$(INCDIR)/foo.h: $(BINDIR)/foomaker envpath PATH=@BINDIR@,@PATH@ foomaker ...
This hides the evaluation of BINDIR and PATH such that clearmake never sees anything but the literals, thus clearing the field for winkins.
Of course envpath is capable of doing more than this, but it's the original reason it was written.
AUTHOR
David Boyce <dsbperl AT boyski.com>
COPYRIGHT
Copyright (c) 2000-2001 David Boyce. All rights reserved. This Perl program is free software; you may redistribute and/or modify it under
the same terms as Perl itself.
SEE ALSO
perl(1), "perldoc Env::Path"
perl v5.10.1 2003-10-10 ENVPATH(1p)