Resolving Gambit-C and Ghostscript /usr/bin/gsc conflict

Ghostscript and Gambit Scheme Compiler both want to use /usr/bin/gsc. I already have Gambit Scheme. How can I resolve this conflict to have a working Ghostscript as well (right now the pacman -S ghostscript terminates with an error about /usr/bin/gsc being present in the system)?
Will installing into the prefix (/usr/local/bin) be a smart idea? That way, the gsc from the earlier PATH entry will respond to 'which gsc'. This will break things for the utilities that require the _other_ gsc.
P.S. Will I be justified in reporting this as a bug?
Last edited by Discriminant (2010-11-29 08:33:03)

Similar Messages

Patch 8557019 - /usr/bin/ld: cannot find -ldeb

Hi there,
I have upgraded an ebs system from 11-5-10-2-1 to r12 12.1.3 - I am in the process of patchiong reports and forms to latest version (10.1.2.3.1)
unfortunately one of the patches errors.
The system is on Linux x86-64
Here is what I did and what I experienced :-
cd /u03/oraupg/inst/apps/oraupg_findbupg/ora/10.1.2
sh oraupg_findbupg.env
linux32 bash
cd /u03/oraupg/apps/patches/10-1-2-patches/8557019
opatch apply
What I experienced :-
[applmgr@findbupg 8557019]$ opatch apply
Oracle Interim Patch Installer version 1.0.0.0.63
Copyright (c) 2009 Oracle Corporation. All Rights Reserved..
Oracle recommends you to use the latest OPatch version
and read the OPatch documentation available in the OPatch/docs
directory for usage. For information about the latest OPatch and
other support-related issues, refer to document ID 293369.1
available on My Oracle Support (https://myoraclesupport.oracle.com)
Oracle Home : /u03/oraupg/apps/tech_st/10.1.2
Oracle Home Inventory : /u03/oraupg/apps/tech_st/10.1.2/inventory
Central Inventory : /u01/oracle/product/oraInventory
from : /etc/oraInst.loc
OUI location : /u03/oraupg/apps/tech_st/10.1.2/oui
OUI shared library : /u03/oraupg/apps/tech_st/10.1.2/oui/lib/linux/liboraInstaller.so
Java location : /u03/oraupg/apps/tech_st/10.1.2/jre/1.4.2/bin/java
Log file location : /u03/oraupg/apps/tech_st/10.1.2/.patch_storage/<patch ID>/*.log
Creating log file "/u03/oraupg/apps/tech_st/10.1.2/.patch_storage/8557019/Apply_8557019_05-31-2011_16-29-40.log"
Invoking fuser to check for active processes.
Provide your email address to be informed of security issues, install and
initiate Oracle Configuration Manager. Easier for you if you use your My
Oracle Support Email address/User Name.
Visit http://www.oracle.com/support/policies.html for details.
Email address/User Name:
You have not provided an email address for notification of security issues.
Do you wish to remain uninformed of security issues ([Y]es, [N]o) [N]: Yes
Oracle Configuration Manager has been installed but not configured. OCM enables
Oracle to provide superior, proactive support for our customers. Oracle
strongly recommends customers configure OCM. To complete the configuration of
OCM, refer to the OCM Installation and Administration Guide
(http://www.oracle.com/technology/documentation/ocm.html).
Backing up comps.xml ...
OPatch detected non-cluster Oracle Home from the inventory and will patch the local system only.
Please shut down Oracle instances running out of this ORACLE_HOME
(Oracle Home = /u03/oraupg/apps/tech_st/10.1.2)
Is this system ready for updating?
Please respond Y|N >
Y
Applying patch 8557019...
Patching archive files...
Running make for target install.
OPatch found the word "error" in stderr, please look into it.
You may have to run the make again.
Stderr Output (from /u03/oraupg/apps/tech_st/10.1.2/.patch_storage/8557019/make_local.stderr):
/usr/bin/ld: skipping incompatible /u03/oraupg/apps/tech_st/10.1.2/lib//libdeb.so when searching for -ldeb
/usr/bin/ld: skipping incompatible /u03/oraupg/apps/tech_st/10.1.2/lib//libdeb.a when searching for -ldeb
/usr/bin/ld: skipping incompatible /u03/oraupg/apps/tech_st/10.1.2/lib//libdeb.so when searching for -ldeb
/usr/bin/ld: skipping incompatible /u03/oraupg/apps/tech_st/10.1.2/lib//libdeb.a when searching for -ldeb
/usr/bin/ld: skipping incompatible /u03/oraupg/apps/tech_st/10.1.2/lib/libdeb.so when searching for -ldeb
/usr/bin/ld: skipping incompatible /u03/oraupg/apps/tech_st/10.1.2/lib/libdeb.a when searching for -ldeb
/usr/bin/ld: cannot find -ldeb
collect2: ld returned 1 exit status
make: *** [dejvm] Error 1
[email protected] - June 1, 2011 9:57:54 AM GMT+12:00 [Update from Customer]
OPatch encounters the following issues during Make:
There were problems running make commands. The errors encounted were:
Error for command: cd /u03/oraupg/apps/tech_st/10.1.2//procbuilder/lib
/usr/bin/make -f ins_procbuilder.mk install ORACLE_HOME="/u03/oraupg/apps/tech_st/10.1.2" 2>/u03/oraupg/apps/tech_st/10.1.2/.patch_storage/8557019/make_local.stderr
Replying 'Y' will terminate the patch installation immediately.It WILL NOT restore any updates that have been performed to this point. It WILL NOT update the inventory.
Replying 'N' will continue with updating the inventory showing the patch has been applied.
NOTE: After replying either 'Y' or 'N' it is critical to review:
My Oracle Support Note 312767.1 How to rollback a failed Interim patch installation.
Do you want to STOP?
Please respond Y|N >
Y
Make Error!
ERROR: OPatch failed during patching, possibly due to missing files.
[applmgr@findbupg 8557019]$
Welcome advice re how to fix this problem - thanks to all who have helped me in the past.
cheers, Rob

Hello Diesel,
As per Note 1266729.1 : "Applying Patch 8557019 and encounter /usr/bin/ld: cannot find -ldeb error running make -f ins_procbuilder.mk install" this can be fixed by appying patch 8551790 first.
Regards, Carlo.

/usr/bin/env

Hi,
I'm trying to find the difference between using env and not using it. Found this:
The env utility is sometimes useful with the ``#!'' construct (see
execve(2)). The only difference between ``#!/usr/local/bin/foo'' and
``#!/usr/bin/env /usr/local/bin/foo'' is that the latter works even if
/usr/local/bin/foo is itself interpreted. Using env this way also allows
one to reference foo without the path, as well as set up the environment
as desired.
Can someone tell me what this means:
The only difference between ``#!/usr/local/bin/foo'' and
``#!/usr/bin/env /usr/local/bin/foo'' is that the latter works even if
/usr/local/bin/foo is itself interpreted.
What is interpreted?
Thanks,

I think I know what this means now.
The shebang line only accepts binary executables. So what it is saying is that if you use env, then the line will accept regular scripts:
#!/usr/bin/env /usr/local/bin/foo
will work even if foo is not a binary executable.
Thanks anyway,

How to change /usr/bin/grep To /usr/local/bin/grep

Hi
I have installed GNU Grep but when I am giving the command #which grep it is showing me solaris grep i.e /usr/bin/grep.
My question is how do I change it to /usr/local/bin/
Thanks in advance
Sukrut

You have a few options:
1) place /usr/local/bin before /usr/bin in your PATH environment variable
2) remove /usr/bin/grep altogether
3) move /usr/bin/grep to something else (ie: /usr/bin/solaris/grep) and symlink /usr/bin/grep to /usr/local/bin/grep just in case any hard coded programs/scripts rely on /usr/bin/grep being present.
I prefer step #3 since most of the various gnu utilities are virtually 100% drop-in replacements.

Odd /usr/bin/kill behavior

I have a Solaris 10 container that I have installed some of the blastwave programs in. Today, I installed and then attempted to stop the milter-greylist daemon which still uses the legacy rc style of initialization.
Running the shutdown script produced the following results:
bash-3.00# /etc/init.d/cswmiltergreylist stop
Shutting down milter-greylist: ... initial gids (should be 0/0): r/egid=0/0
SETUP ERROR: re-run set-group-ID guest
Use chgrp(1) and chmod(1)
For example, do this as root (nobody is the name of a group in this example):
# chgrp nobody /usr/bin/kill
# chmod g+s nobody /usr/bin/kill
done
and running /usr/bin/kill on its own resulted in this:
bash-3.00# /usr/bin/kill
initial gids (should be 0/0): r/egid=0/0
SETUP ERROR: re-run set-group-ID guest
Use chgrp(1) and chmod(1)
For example, do this as root (nobody is the name of a group in this example):
# chgrp nobody /usr/bin/kill
# chmod g+s nobody /usr/bin/kill
The size of /usr/bin/kill on this computer's global zone is different from my other Solaris 10 servers.
This host:
bash-3.00# ls -l /usr/bin/kill
-r-xr-xr-x 1 root root 7772 Feb 26 12:23 /usr/bin/kill
Another Solaris 10 host:
bash-3.00# ls -l /usr/bin/kill
-r-xr-xr-x 17 root bin 134 Jan 21 2005 /usr/bin/kill
I tried checking the md5 sum of /usr/bin/kill in the Solaris fingerprint database, but don't believe that it covers Solaris 10.
Has anyone else seen this behavior and what did you do about it?
TIA

"it seems that I accidentally installed something"... so you can't recall installing any such thing?
I can't even imagine which tool or package might replace /bin/kill..
If core system utilities suddenly change behaviour or file size, you might have a rootkit on that box. Better run a thorough check.. or reinstall.
Especially if the new file version is about fifty times as big.. that smells like it contains unexpected additional "features" now. At least compare file sizes of the other core system binaries to your other host..

Are /usr/ubc binaries different than /usr/bin binaries?

Hi,
I am running SunOS 5.8 and I have following questions about solaris distribution:
1. Are /usr/ucb binaries different than regular binaries like /usr/bin etc...
Because at file level they appear to be the same:
e.g. ps
$ ls -ltr /usr/ucb/ps /usr/bin/ps
-r-xr-xr-x 38 root bin 5.2K Jan 5 2000 /usr/ucb/ps
-r-xr-xr-x 38 root bin 5.2K Jan 5 2000 /usr/bin/ps
2. Are /usr/ubc binaries are part of standared solaris distribution?
Thanks

Hi,
I am running SunOS 5.8 on SPARC I assume...
and I have following
questions about solaris distribution:
1. Are /usr/ucb binaries different than regular
binaries like /usr/bin etc...Yup (at least most of the time). /usr/ucb/ gives some behavior of older BSD systems for compatibility.
Because at file level they appear to be the same:
e.g. ps
$ ls -ltr /usr/ucb/ps /usr/bin/ps
-r-xr-xr-x 38 root bin 5.2K Jan 5 2000 /usr/ucb/ps
-r-xr-xr-x 38 root bin 5.2K Jan 5 2000 /usr/bin/psThis is a side effect of a feature called 'isaexec'. You'll notice the link count is 38, so this file is linked as 38 different names.
The 'ps' command looks through /proc, so the binary has to match the currently running kernel architecture (whether 32-bit or 64-bit). 'isaexec' allows you to have multiple binaries that are called properly based on architecture.
On my machine:
# ls -litr /usr/ucb/ps /usr/bin/ps /usr/lib/isaexec
18227 -r-xr-xr-x 37 root bin 5256 Jan 5 2000 /usr/ucb/ps
18227 -r-xr-xr-x 37 root bin 5256 Jan 5 2000 /usr/lib/isaexec
18227 -r-xr-xr-x 37 root bin 5256 Jan 5 2000 /usr/bin/ps
So all 'isaexec' does is look for a binary with the same name as it was called in the architecture specific directories. So for /usr/ucb/ps, it's these:
# ls -l /usr/ucb/sparcv7/ps /usr/ucb/sparcv9/ps
-r-xr-xr-x 1 root sys 23504 Jul 15 2005 /usr/ucb/sparcv7/ps
-r-xr-xr-x 1 root sys 32264 Jul 15 2005 /usr/ucb/sparcv9/ps
And for /usr/bin/ps It's these:
# ls -l /usr/bin/sparcv7/ps /usr/bin/sparcv9/ps
-r-sr-xr-x 1 root sys 29196 Jul 15 2005 /usr/bin/sparcv7/ps
-r-sr-xr-x 1 root sys 38536 Jul 15 2005 /usr/bin/sparcv9/ps
So different binaries (and different architectures):
# file /usr/bin/sparcv7/ps /usr/bin/sparcv9/ps /usr/ucb/sparcv7/ps /usr/ucb/sparcv9/ps
/usr/bin/sparcv7/ps: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped
/usr/bin/sparcv9/ps: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, stripped
/usr/ucb/sparcv7/ps: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped
And you can use 'truss' to see how this works:
/usr/ucb/sparcv9/ps: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, stripped
Note that this feature (isaexec) has nothing specifically to do with /usr/ucb. It's used by any system binary that needs separate versions for 32-bit vs 64-bit to run properly. (truss, p*, uptime, ...)
2. Are /usr/ubc binaries are part of standared
solaris distribution?There's only one "Solaris" distribution, so yes. I believe they get installed at the 'user' installation level and above, but you'd have to check on that.
Darren

Where do i find the file /usr/bin/swg/ ?

Hi,
I am backing up my hard drive for the first time with Time Machine, and have been getting error messages that stop the backup process. I downloaded Time Machine Buddy and used the logs to locate and exclude problem-causing files, however I cannot locate this file:
Error: (-36) SrcErr:NO Copying/usr/bin/swg/ - would appreciate if someone could tell me where it is, and if it is a vital file. Thanks!

1. Choose Go to Folder from the Finder's Go menu and provide /usr/bin/ as the path.
2. Assuming the item is named swg, it's not installed by the core OS or iLife. Other software may require it to work. Note that the core OS includes swig in the bin folder.
(66512)

Command Line Tools installs the latest version of clang (and others) in /Library/Developer/CommandLineTools/... but not in /usr/bin/

I've upgraded Xcode to the latest 5.1 Installed Command Line Tools via xcode-select --install Homebrew tells me "A newer Command Line Tools release is available"
brew --config:
Xcode: 5.1 CLT: 5.1.0.0.1.1393561416 LLVM-GCC: build 2336 Clang: 3.1 build 318
Checking my clang executable:
$ /usr/bin/clang --version Apple clang version 3.1 (tags/Apple/clang-318.0.58) (based on LLVM 3.1svn)
$ /Library/Developer/CommandLineTools/usr/bin/clang --version Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
So it appears Command Line Tools didn't install clang (and perhaps other executables) into /usr/bin? I checked my other laptop (w/ Mavericks), and /usr/bin/clang is version 5.1.
So I'm guessing this is the problem? I've tried to reinstall Command Line Tools as sudo, but now it won't let me install again (says software isn't currently available).
Can anyone help me with this? I've spent hours on it now, but can't find a solution.
Thanks

BTW, I installed Xcode 5.1 from the Store, but have never run xcode-select --install. Here is the verbose output from a clang.
xew ~/$:clang -v -o hello main.c
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain /usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.9.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name main.c -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 236.3 -v -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/ usr/bin/../lib/clang/5.1 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/ SDKs/MacOSX10.9.sdk -fdebug-compilation-dir /Users/xew -ferror-limit 19 -fmessage-length 100 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.9.0 -fencode-extended-block-signature -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -o /var/folders/zf/d5vqmmtn5mq7h6766jtlkrvr0000gn/T/main-353995.o -x c main.c
clang -cc1 version 5.1 based upon LLVM 3.4svn default target x86_64-apple-darwin13.1.0
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer /SDKs/MacOSX10.9.sdk/usr/local/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer /SDKs/MacOSX10.9.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/ usr/bin/../lib/clang/5.1/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/ usr/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/ SDKs/MacOSX10.9.sdk/usr/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/ SDKs/MacOSX10.9.sdk/System/Library/Frameworks (framework directory)
End of search list.
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain /usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.9.0 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/ SDKs/MacOSX10.9.sdk -o hello /var/folders/zf/d5vqmmtn5mq7h6766jtlkrvr0000gn/T/main-353995.o -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/ usr/bin/../lib/clang/5.1/lib/darwin/libclang_rt.osx.a
xew ~/$:

Cannot open registry key and /usr/bin/lib: invalid option --N patch 7237313

Hi,
I am trying to install autoconfig TXK patch 7237313 for cloning an EBS 12 on windows server 2003.
When I run adpatch it returns 2 errors:
*1 -*
setEnvAdrelink: Error: Cannot open registry key:
SOFTWARE\ORACLE
*2 -*
Relinking module 'CONCSUB.exe' in product fnd ...
gnumake -f E:/oracle/PROD/apps/apps_st/appl/admin/PROD/out/link_fnd_2548.mk E:/o
racle/PROD/apps/apps_st/appl/fnd/12.0.0/bin/CONCSUB.exe
Starting link of fnd executable 'CONCSUB.exe' on Fri Feb 5 09:25:07 SAST 2010
/usr/bin/lib: invalid option -- N
Try `/usr/bin/lib --help' for more information.
E:/oracle/PROD/apps/apps_st/appl/admin/PROD/out/link_fnd_2548.mk:2901: warning:
overriding commands for target `E:/oracle/PROD/apps/apps_st/appl/fnd/12.0.0/bin/
CMDCART.dll'
E:/oracle/PROD/apps/apps_st/appl/admin/PROD/out/link_fnd_2548.mk:752: warning: i
gnoring old commands for target `E:/oracle/PROD/apps/apps_st/appl/fnd/12.0.0/bin
/CMDCART.dll'
E:/oracle/PROD/apps/apps_st/appl/admin/PROD/out/link_fnd_2548.mk:2948: warning:
overriding commands for target `E:/oracle/PROD/apps/apps_st/appl/fnd/12.0.0/bin/
FNDRTR45.exe'
E:/oracle/PROD/apps/apps_st/appl/admin/PROD/out/link_fnd_2548.mk:1333: warning:
ignoring old commands for target `E:/oracle/PROD/apps/apps_st/appl/fnd/12.0.0/bi
n/FNDRTR45.exe'
link.exe -MAP:E:/oracle/PROD/apps/apps_st/appl/fnd/12.0.0/bin/CONCSUB.map -NODEF
AULTLIB -NOLOGO -SUBSYSTEM:CONSOLE -ENTRY:mainCRTStartup -OUT:E:/oracle/PROD/app
s/apps_st/appl/fnd/12.0.0/bin/CONCSUB.exe E:/oracle/PROD/apps/apps_st/appl/fnd/1
2.0.0/lib/fdpocr.obj \
E:/oracle/PROD/apps/apps_st/appl/fnd/12.0.0/lib/FNDCORE.lib E:/oracle/PR
OD/apps/tech_st/10.1.2/precomp/lib/msvc/orasql10.lib E:/oracle/PROD/apps/tech_st
/10.1.2/precomp/lib/msvc/orasqx10.lib E:/oracle/PROD/apps/tech_st/10.1.2/RDBMS/l
ib/oraclient10.lib E:/oracle/PROD/apps/tech_st/10.1.2/RDBMS/lib/oracommon10.lib
E:/oracle/PROD/apps/tech_st/10.1.2/NETWORK/lib/oranro10.lib E:/oracle/PROD/apps/
tech_st/10.1.2/NETWORK/lib/oran10.lib E:/oracle/PROD/apps/tech_st/10.1.2/NETWORK
/lib/oranl10.lib E:/oracle/PROD/apps/tech_st/10.1.2/lib/oranls10.lib E:/oracle/P
ROD/apps/tech_st/10.1.2/lib/oracore10.lib /LIB/MSVCRT.LIB /LIB/OLDNAMES.LIB /P
latformSDK/LIB/KERNEL32.LIB /PlatformSDK/LIB/USER32.LIB /PlatformSDK/LIB/ADVAPI3
2.LIB /PlatformSDK/LIB/WINSPOOL.LIB /PlatformSDK/LIB/COMDLG32.LIB /PlatformSDK/L
IB/GDI32.LIB /PlatformSDK/LIB/VERSION.LIB
link: invalid option -- M
Try `link --help' for more information.
gnumake: *** [E:/oracle/PROD/apps/apps_st/appl/fnd/12.0.0/bin/CONCSUB.exe] Error
1
Done with link of fnd executable 'CONCSUB.exe' on Fri Feb 5 09:25:08 SAST 2010
Relink of module "CONCSUB.exe" failed.
See error messages above (also recorded in log file) for possible
reasons for the failure. Also, please check that the Unix userid
running adrelink has read, write, and execute permissions
on the directory E:/oracle/PROD/apps/apps_st/appl/fnd/12.0.0/bin,
and that there is sufficient space remaining on the disk partition
containing your Oracle Applications installation.
egrep version is 2.5.1 and gnumake is 3.80.
please help,
regards,
Hassane Cabir

Hi,
Are the application services down?
setEnvAdrelink: Error: Cannot open registry key:
SOFTWARE\ORACLEyes, the services are down, using adstpall.cmd and Maintenance mode enabled using adadmin.
Get the version 3.80-1 of the make file -- See (Note: 414992.1 - Using Cygwin to Maintain Oracle E-Business Suite Release 12 on Windows).The make is already 3.80-1.
regards,
Hassane Cabir

/usr/local/bin vs /usr/bin and Kazehakase vs Firefox

When you install an application to /usr/bin will it be more faster than installed on /usr/local/bin?
I have Firefox installed in /usr/bin and Kazehakase installed to /usr/local/bin. And it seems that Firefox is faster than Kazehakase. Why?
Last edited by Paingiver (2008-03-15 11:11:48)

dyscoria wrote:
Endperform wrote:The notion that an application can be sped up by linking it in your home directory, or even renaming it to one letter is also crazy. Your install will search for an executable in the path specified in $PATH and then execute the first instance it finds, but this does NOT speed the application itself up.
No seriously, if you rename all your executables to one letter then your system runs like lightning!
* am i really that bad at sarcasm? *
Yes, since there was no indication of sarcasm in your post. A or would have worked

What does this error message mean and how do I solve it? "Sorry, one or more of the following command-line tools was not found: /usr/bin/lsbom, /bin/pax, /bin/mkdir, /bin/chmod, or /usr/bin/update_prebinding."

When I try to open up this program, Pacifist, I receive this error message. Here's a screenshot. http://i.imgur.com/v717w.jpg What does this error message mean and how do I solve it?

It sounds like some of the Unix Executable commands were removed (or the permissions to those were modified) out of the /usr/bin/ folder. You can try opening disk utility and repairing permissions on Macintosh HD or you can reboot your computer and holding down option-r when it comes back up to reinstall Lion again. This will not delete your personal information or applications you have installed but it would be best to back it up to Time Machine before you do. The article on how to do this is here. (http://www.apple.com/macosx/recovery/) I have had to do this before and it works like a charm. It should fix your issue but grab a cup of coffee because its going to take about 35 - 40 minutes depending on how fast your computer is.

Fedora merging /usr/bin with /sbin and /bin

I just read this mail on the fedora list regaring the proposal to merge the different directories for binaries:
https://lists.fedoraproject.org/piperma … 58845.html
It does seem like a practice from times long gone.
What is your take on this? Wouldn't this be something in the spirit of Arch, too?

I came across this interesting proposal and was interested how the Archlinux community feels about this:
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge wrote:
Improved compatibility with other Unixes/Linuxes in behaviour: After the /usr merge all binaries become available in both /bin and /usr/bin, resp. both /sbin and /usr/sbin (simply because /bin becomes a symlink to /usr/bin, resp. /sbin to /usr/sbin). That means scripts/programs written for other Unixes or other Linuxes and ported to your distribution will no longer need fixing for the file system paths of the binaries called, which is otherwise a major source of frustration. /usr/bin and /bin (resp. /usr/sbin and /sbin) become entirely equivalent.
Improved compatibility with other Unixes (in particular Solaris) in appearance: The primary commercial Unix implementation is nowadays Oracle Solaris. Solaris has already completed the same /usr merge in Solaris 11. By making the same change in Linux we minimize the difference towards the primary Unix implementation, thus easing portability from Solaris.
Improved compatibility with GNU build systems: The biggest part of Linux software is built with GNU autoconf/automake (i.e. GNU autotools), which are unaware of the Linux-specific /usr split. Maintaining the /usr split requires non-trivial project-specific handling in the upstream build system, and in your distribution's packages. With the /usr merge, this work becomes unnecessary and porting packages to Linux becomes simpler.
Improved compatibility with current upstream development: In order to minimize the delta from your Linux distribution to upstream development the /usr merge is key.

/usr/bin changes and grub legacy

Hello,
Grub legacy is one of the packages that keeps its binaries in /sbin. I'm just wondering if this means that I have to replace grub legacy with another bootloader before I upgrade my system? I certainly wouldn't know how to update grub legacy so that the binaries are found in /usr/bin.
Thanks.

The reason to change to systemd is that the daemon scripts in /etc/rc.d are disappearing, as are hte /etc/conf.d stuff. It will break sooner or later (probably sooner) and I am actually really surprised it hasn't already. There is a reason why the news indicated that you should switch, as the old initscripts are not longer supported. That means more than just not getting updates, the files that make that work are slowly being pulled from the packages (and slowly in Arch is not very slow at all).
As for consolekit, it is an unmaintained piece of software. Its functionality has been replcaed by systemd's logind (quite successfully I mgith add) which is another reason why you should switch.
I'm not saying that you have to switch, as there are other alternatives out there that you could use. There is a whole thread on how to use openrc, and some stuff about using various other thigns as well, like runit or even the busybox init. But I have seen very little quality stuff in regard to maintenance of the old initscripts. Sticking with this is not something you should really want to do. I think in the end, you will end up with a much larger headache than simply ironing out any issues may have with moving to systemd.

What shell script found in /usr/sbin and /usr/bin in OS X made out off?

What shell script found in /usr/sbin and /usr/bin in OS X made out off?
thanks.

You may have to provide more detail on what you're wanting to know if this doesn't answer your question.
Shell scripts are just text files. You can create or open them with any text editor. They are executed by one of the command interpreters (such as sh, bash, csh, etc) or by a language interpreter (like perl or ruby). However, many of the items in the directories you mention are not shell scripts but rather binary executables. These are executed by the OS.
You can use something like this to show you which are which:
file /usr/bin/*
Steve

HT5730 Lost content on /usr/bin/ and .bash_profile

I've installed the update and it seems to have reset my .bash_profile.
It also seems to have removed some programs I had installed under /usr/bin like Git and Macports among others.
This is a big let down for me, coming from Apple.

Posix standards have nothing to do with Apple. /usr/bin/ is reserved for binary files delivered from the distribution. /usr/local/bin is available for administrators to add binary files which will not be touched by an update. If you wish to install in /usr/bin then it is YOUR responsibility to maintain the added binaries. MacPorts normally installs in the opt/local/ directory did you customize your installation?
For some reason /opt/local/bin was removed from my PATH. But yes, MacPorts was actually still installed in that folder.
I installed Git through the Command Line Tools installation from Xcode, so I didn't choose anything.
Nevertheless, I did not expect any update to remove anything I've installed on my system nor mess with my home folder without first warning me about it .

Resolving Gambit-C and Ghostscript /usr/bin/gsc conflict

Similar Messages

Maybe you are looking for