'Reverse' ldd ??
Bombadil
a given library is linked to?
You can run
ldd /usr/sbin/gpm
linux-gate.so.1 => (0xffffe000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7e20000)
/lib/ld-linux.so.2 (0xb7f40000)
What I'd _really_ like to able to do is
foo /lib/libc.so.6
and have it list /usr/sbin/gpm
and all of the other executables it is linked to,
which would all of them in this case, making it
a poor example, but you get my drift.
Anyone have a clue? I struck out with google.
Thanks,
Bombadil
Nathan Keel
No, I don't believe this is possible, not without some database or
something to track that, and ldd doesn't do that. You could run ldd or
other tools against all of the binaries or maybe RPMs and get different
information to track, but I'm not aware of any reverse ldd and I can't
think of a reason to want it.
Keith Keller
>
> No, I don't believe this is possible, not without some database or
> something to track that, and ldd doesn't do that. You could run ldd or
> other tools against all of the binaries or maybe RPMs and get different
> information to track, but I'm not aware of any reverse ldd and I can't
> think of a reason to want it.
The reason to want it is to determine whether a given library could be
deleted or not. On most modern disks this is sort of pointless, but I
can see how one might need the space on a very tight system (e.g., a
ramdisk or a much older machine pushed into service).
If one were completely crazy, one could do a find from /, run that
through file, grep out which files are ELF executable (or if you have
different binary formats, whichever you use), and run ldd on those
files, and somehow parse that out and save it to a database. But that
sounds completely crazy.
--keith
--
kkeller...@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
Robert Heller
#!/usr/bin/tclsh
set bins {}
foreach p [split $::env(PATH) :] {
lappend bins [file join $p *]
}
foreach f [eval [list glob -nocomplain] $bins] {
if {[catch {exec ldd $f | grep -q [lindex $argv 0]}]} {continue}
puts $f
}
>
> Thanks,
>
> Bombadil
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Download the Model Railroad System
http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows
hel...@deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/
Robert Heller
>
> On 2009-05-04, Nathan Keel <na...@gm.ml> wrote:
> >
> > No, I don't believe this is possible, not without some database or
> > something to track that, and ldd doesn't do that. You could run ldd or
> > other tools against all of the binaries or maybe RPMs and get different
> > information to track, but I'm not aware of any reverse ldd and I can't
> > think of a reason to want it.
>
> The reason to want it is to determine whether a given library could be
> deleted or not. On most modern disks this is sort of pointless, but I
> can see how one might need the space on a very tight system (e.g., a
> ramdisk or a much older machine pushed into service).
In the case of a 'ramdisk' based system, you can look at 'BusyBox'.
BusyBox is a statically link executable that includes the functionallity
of many separate programs, including several shells.
>
> If one were completely crazy, one could do a find from /, run that
> through file, grep out which files are ELF executable (or if you have
> different binary formats, whichever you use), and run ldd on those
> files, and somehow parse that out and save it to a database. But that
> sounds completely crazy.
If you just want to install a mini system on a small disk, you can use
the package management systems that most distros use. These package
management systems keep track of what packages are needed by which
packages (in your case, which lib* packages are needed for various
uilitity packages). This is actually a better way to deal with this.
There is more going on than just ELF's and .so files. There are other
dependencies: config files, documentation, support scripts, etc. All of
this eats disk space.
Your "... find from /, run that through file, grep out which files are ELF
executable, and run ldd on those files, and somehow parse that out and
save it to a database." is esentually what programs like rpmbuild in
fact do, just for a single package at a time and stores the information
in the RPM file. When the package gets installed, the rpm command adds
the package's dependencies to RPM's database. I assume dpkg does
something similar in the Debian world (rpm is the base package manager
in the RedHat world). It is not completely crazy. It is part of what
package management systems take care of for you. There is no need to
'reinvent' the wheel...
>
> --keith
Mark Hobley
> No, I don't believe this is possible, not without some database or
> something to track that
You might be able to get this from the dependency tree in the package datadase,
but I don't know what facilities are available. I was looking for a package
that creates a dependency tree diagram (for Debian in my case). This would
enable me to see visually which packages relied on which libraries, and also
packages depending on other packages. I didn't find anything last time I
looked, but it was a while ago.
Mark.
--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/
Nathan Keel
That's what I'd probably plan to do myself, if I was going for such a
goal. I wouldn't think it would be difficult to do, but it could take
a while the first time and again for any changes on the system.
Bombadil
> On 2009-05-04, Nathan Keel <na...@gm.ml> wrote:
>>
>> No, I don't believe this is possible, not without some database or
>> something to track that, and ldd doesn't do that. You could run ldd or
>> other tools against all of the binaries or maybe RPMs and get different
>> information to track, but I'm not aware of any reverse ldd and I can't
>> think of a reason to want it.
>
> The reason to want it is to determine whether a given library could be
> deleted or not. On most modern disks this is sort of pointless, but I
> can see how one might need the space on a very tight system (e.g., a
> ramdisk or a much older machine pushed into service).
That's it. Right on the money. I don't like unused stuff cluttering
up my system.
>
> If one were completely crazy, one could do a find from /, run that
> through file, grep out which files are ELF executable (or if you have
> different binary formats, whichever you use), and run ldd on those
> files, and somehow parse that out and save it to a database. But that
> sounds completely crazy.
No. It sounds perfectly reasonable. Just another database like
locate and whatis. Thanks for the idea.
Bombadil
Bombadil
> At 4 May 2009 23:08:51 +0100 Bombadil <jus...@hometown.invalid> wrote:
>
>>
>> Is there a utility that will tell a person what _executables_
>> a given library is linked to?
>>
>> You can run
>>
>> ldd /usr/sbin/gpm
>> linux-gate.so.1 => (0xffffe000)
>> libc.so.6 => /lib/tls/libc.so.6 (0xb7e20000)
>> /lib/ld-linux.so.2 (0xb7f40000)
>>
>> What I'd _really_ like to able to do is
>>
>> foo /lib/libc.so.6
>>
>> and have it list /usr/sbin/gpm
>>
>> and all of the other executables it is linked to,
>> which would all of them in this case, making it
>> a poor example, but you get my drift.
>>
>> Anyone have a clue? I struck out with google.
>
> #!/usr/bin/tclsh
>
> set bins {}
> foreach p [split $::env(PATH) :] {
> lappend bins [file join $p *]
> }
>
> foreach f [eval [list glob -nocomplain] $bins] {
> if {[catch {exec ldd $f | grep -q [lindex $argv 0]}]} {continue}
> puts $f
> }
Gee thanks. A script in a scripting language I've never even
heard of.
I'll just run right out and install it.
When your meds kick in, try bash.
Bombadil
Bombadil
Thanks. Keith explained the reason for it.
Bombadil
Nathan Keel
By berate the guy for posting the tclsh script? It's just the TCL
interpreter and if you know much bash at all, you can see exactly what
it's doing. I don't see the reason to insult the person for posting
help.
Nathan Keel
>
> That's it. Right on the money. I don't like unused stuff cluttering
> up my system.
>
I had an incling of why you might want to, but I've not seen any system
so jammed up with unused libraries, etc. that it's going to really save
room. The time it would take to really decide what's safe and
appropriate to move, even with a database showing what binaries might
be looking for it (assuming it won't default to an older or newer one)
could take a lot of time for very little reward.
Of course, I'm not suggesting not doing what you want, for any reason
you want to, but you'll want to check a lot of various files all over
the file system, and that could be huge and annoying to try and tackle.
Usually, if you build from source the right way, or use some package
manager, it'll do all of that for you. Anyway, I guess I needn't say
you should be careful doing these things. I don't really think the
results will be worth the effort, but your situation might be
different. Good luck.
Harold Stevens
[Snip...]
> When your meds kick in, try bash.
For a beggar, you're arrogantly choosy. Buh-bye...
--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at airmail, dotted with net. DO NOT SPAM IT.
I toss GoogleGroup posts from gitgo (http://improve-usenet.org).
Keith Keller
>
> If you just want to install a mini system on a small disk, you can use
> the package management systems that most distros use.
I chose not to assume that the OP was using one of these distros.
Slackware, for example, is a great choice for such a mini system where
the package manager does not manage dependencies. (Rolling one's own
system would also be such a case, though presumably one already knows
what the dependencies are in that situation.)
Keith Keller
> Robert Heller <hel...@deepsoft.com> wrote:
>>
>
> Gee thanks. A script in a scripting language I've never even
> heard of.
You haven't heard of Tcl? It's actually a worthwhile language, though
on a minimal system you may not have it installed.
Bombadil
Thanks. I think it's worth a real script. Leaving unnecessary
executables laying around doesn't seem wise. And libs _are_
executables.
Bombadil
Bombadil
But on the other hand, I have been using linux for a long time
and have never heard of tclsh and even though I know a couple
of weird scripting languages, I wouldn't post scripts them as solutions
to problems on the usenet, because I know that other people
don't use them and that bash is what everyone does use, more or less.
Bombadil
Bombadil
> On 2009-05-05, Bombadil <jus...@hometown.invalid> wrote:
>> Robert Heller <hel...@deepsoft.com> wrote:
>>>
>>> #!/usr/bin/tclsh
>>
>> Gee thanks. A script in a scripting language I've never even
>> heard of.
>
> You haven't heard of Tcl? It's actually a worthwhile language, though
> on a minimal system you may not have it installed.
>
I've heard of Tcl, but not tclsh. But even if I knew the language
I wouldn't offer scripts in it as solutions on the usenet or any
other general linux forum. Bash is the lingua franca of the linux
world, not tcl or slang or...
Bombadil
Bill Marcum
use the package database. On a Debian-based system "apt-cache rdepends libc6"
Bombadil
Hello Bill. I'm using a 'stripped down' Slackware. One of the nice things about
Slackware is its simple, straightforward package management system, which
is just a bunch of bash scripts. It has no bells and whistles like that,
but that's okay, because it never breaks down and never goes crazy like
apt and rpm and the like. And you don't need the equivalent of a serious
college course to use it effectively.
I do use quite a few Debian packages, though. At least the executables
and docs in them. And you can get a list of dependencies on their website.
It's just time-consuming and some of them are distro-specific. I've
noticed that some of the executables don't use all the libs on my system
that Debian says are necessary.
Thanks,
Bombadil
Robert Heller
apt-get install tcl
yum instal tcl
It might already be installed though. Tcl is commonly used by a number
of packages.
The above code was just an example of how to create a 'reverse lookup'
using ldd itself. Feel free to re-code it in the scripting language of
your choice.
>
> When your meds kick in, try bash.
>
> Bombadil
>
>
>
>
--
Hactar
What is "libc6"? It's not the basename of the library minus extensions:
eben@pc:~$ find / /usr -xdev -name \*sshnodelay\* 2> /dev/null
/usr/lib/sshnodelay.so
eben@pc:~$ apt-cache rdepends sshnodelay
W: Unable to locate package sshnodelay
"Package not found"? Ah, it's a package name. How do I get a package
name from a library name? Does a package uniquely identify a library?
Guessing the package "ssh" is valid:
eben@pc:~$ apt-cache rdepends ssh
ssh
Reverse Depends:
ssh-askpass-gnome
|ssh-askpass-gnome
openssh-server
openssh-server
(58 more lines)
How do I associate executables with the package "openssh-server", for
instance?
--
-eben QebWe...@vTerYizUonI.nOetP http://royalty.mine.nu:81
An ASCII character walks into a bar and orders a double. "Having a bad
day?" asks the barman. "Yeah, I have a parity error," replies the ASCII
chrcter. The barman says, "Yeah, I thought you looked a bit off." - Skud
Bombadil
I run slackware, which you'd know if you bothered to read the thread.
But more importantly, I do not install software because some elitist
jerk posts a code snippet in an obscure scripting language (compared
to bash, which is what should be used on a general linux group).
> It might already be installed though. Tcl is commonly used by a number
> of packages.
Don't have it. That should be obvious to you.
> The above code was just an example of how to create a 'reverse lookup'
> using ldd itself. Feel free to re-code it in the scripting language of
> your choice.
And how I am supposed to do that when I don't understand the scripting
language you used and it isn't even commented?
Uncommented code is the sign of an amateur or an incompetent, especially
in a situation like this.
>> When your meds kick in, try bash.
That bears repeating.
Bombadil
Robert Heller
I would guess you would use the dpkg equivalent to 'rpm -ql' (-ql ==
query+list), unless apt-cache implements this functionallity itself.
dpkg is the underlying package manager for Debian-based distros:
Debian, Ubuntu, etc. rpm is the underlying package manager for
RedHat-based distros: RHEL, CentOS, WBL, Suse, Mandrake, Fedora, et.
al.
Keith Keller
>
> in a situation like this.
You should really read the newsgroup more before making a comment like
this. Robert has made many interesting and useful posts over the years
I've been reading. Unless you really don't want that help (sure,
perhaps this time he wasn't helpful to you, but next time he might be)
you might want to stop antagonizing him.
Bill Marcum
and "dpkg -S" finds the name of the package for a given file name.
Unfortunately, none of this applies to Slackware, which is what the OP
uses.
Bombadil
> On 2009-05-05, Bombadil <jus...@hometown.invalid> wrote:
>>
>> Uncommented code is the sign of an amateur or an incompetent, especially
>> in a situation like this.
>
> You should really read the newsgroup more before making a comment like
> this. Robert has made many interesting and useful posts over the years
> I've been reading. Unless you really don't want that help (sure,
> perhaps this time he wasn't helpful to you, but next time he might be)
> you might want to stop antagonizing him.
Thanks, Keith. But I think he needs 'antagonizing' in this case.
He's so far out of line that he can't even see it.
Bombadil
Bombadil
:-) That's okay. Others will find it useful. It's not 'unfortunate'
anyway. At least I don't have to worry about my package management
system going crazy or failing, which those complex ones do on
occassion. And I don't have to have the equivalent of a difficult
and long college course to use it effectively. And I save a LOT
disk space for other purposes. Package management systems like
rpm and apt are monsters.
I'll just write a bash script that will make a 'database' of
the information I need. No big deal.
Bombadil
Jules
> At least I don't have to worry about my package management
> system going crazy or failing, which those complex ones do on
> occassion. And I don't have to have the equivalent of a difficult
> and long college course to use it effectively. And I save a LOT
> disk space for other purposes. Package management systems like
> rpm and apt are monsters.
Hmm, I always think packages are a bit too coarse-grain, resulting in
systems that are far too bloated. I suspect that something which gives the
user finer control over what they have installed could be achieved, but
possibly only if there was a packaging framework that was a core part of
Linux, rather than every distro slapping package management on as an
afterthought.
Personally I'm a happy Slackware user and always will be, I think.
cheers
Jules
Mark Hobley
> That's what I'd probably plan to do myself, if I was going for such a
> goal. I wouldn't think it would be difficult to do, but it could take
> a while the first time and again for any changes on the system.
You need some good documentation on the package database layout. I started to
make some notes on the Debian database, for the purpose of detailing and cross
referencing its internal fields, and how they are obtained from the packages.
However, I am planning to use a different system now, so my notes will
just get archived in an unfinished state. I do push what I can out onto Debian
wiki, but it usually gets deleted with a "refer to official documentation"
(which does not contain sufficient information, or is not sufficiently
cross-referenced to be useful.)
Balwinder S Dheeman
BTW, Aren't you trying to reinvent the wheel?
Each and every package, operating-system, distribution and, or said
package-management-system have its pros and cons; nothing in this world
is perfect, not even the God, so why don't we appreciate the resources,
hours and effort the volunteers are or have been investing for us for
whatever reason.
See http://tinyurl.com/dgcgvn page, how people are wasting time on
discussing absurd topics.
Linux is much much better, though not the best as yet, Do you too work
on making a difference?
--
Balwinder S "bdheeman" Dheeman Registered Linux User: #229709
Anu'z Linux@HOME (Unix Shoppe) Machines: #168573, 170593, 259192
Chandigarh, UT, 160062, India Plan9, T2, Arch/Debian/FreeBSD/XP
Home: http://cto.homelinux.net/~bsd/ Visit: http://counter.li.org/
Bombadil
No. I'm just ignoring fools who have squared them off.
> Each and every package, operating-system, distribution and, or said
> package-management-system have its pros and cons; nothing in this world
> is perfect, not even the God, so why don't we appreciate the resources,
> hours and effort the volunteers are or have been investing for us for
> whatever reason.
If you want to install package management systems that can trash
your system without warning, or go bonkers and require 100 hours
of your time to fix and require a college degree to use
effectively, you go ahead.
>
> See http://tinyurl.com/dgcgvn page, how people are wasting time on
> discussing absurd topics.
I'll pass.
>
> Linux is much much better, though not the best as yet, Do you too work
> on making a difference?
Linux is much worse than it was. Now it is being redesigned in the
image of MicroSoft by sellout geeks.
No sale.
Bombadil
Bombadil
Good thinking.
>
> Personally I'm a happy Slackware user and always will be, I think.
Me too. But largely because it is so easy to customize. I don't
like the way Volkerding has sold out to the big corporations and
wouldn't do a default install if you paid me.
Bombadil
Nathan Keel
I understand the intent, but you shouldn't have random libraries around
to be executed, if things are updated properly. Besides, a library is
only a risk if a program uses the old one, and it shouldn't, so old
libraries shouldn't technically be a problem or security risk. Anyway,
this could be an interesting project for you to do regardless of the
whys.
Nathan Keel
I see, you should consider adding a smiley next time so people know.
> But on the other hand, I have been using linux for a long time
> and have never heard of tclsh and even though I know a couple
> of weird scripting languages,
There's a lot out there, not a lot of people know it all.
> I wouldn't post scripts them as
> solutions to problems on the usenet, because I know that other people
> don't use them and that bash is what everyone does use, more or less.
>
> Bombadil
I don't agree, people either are willing to run a solution in script
form or not (either taking time to figure if it's safe or not). I
don't see the problem, but it would take only a minute to recode that
in bash if you prefer, so maybe do that?
Nathan Keel
Maybe in your experience, but not everyone's. A lot of korn shell are
used, as well as a great deal of Perl code/scripts. I use Perl more
than bash, for example.
Bombadil
> Bombadil wrote:
<snippity>
Nathan said, referring to scripting languages:
> There's a lot out there, not a lot of people know it all.
>
>> I wouldn't post scripts them as
>> solutions to problems on the usenet, because I know that other people
>> don't use them and that bash is what everyone does use, more or less.
>>
>> Bombadil
>
> I don't agree, people either are willing to run a solution in script
> form or not (either taking time to figure if it's safe or not). I
> don't see the problem, but it would take only a minute to recode that
> in bash if you prefer, so maybe do that?
>
In order recode scripts you have to know BOTH languages. I am not
learning a new language in order to recode a snippet. Are you nuts?
In response to your other article, bash is _by_far_ the most commonly
used scripting language in linux. People who post solutions in
(relatively) obscure scripting languages on general linux forums
are being elistist jerks.
Bombadil
Nathan Keel
> Nathan Keel <na...@gm.ml> wrote:
>> Bombadil wrote:
>
> <snippity>
>
> Nathan said, referring to scripting languages:
>> There's a lot out there, not a lot of people know it all.
>>
>>> I wouldn't post scripts them as
>>> solutions to problems on the usenet, because I know that other
>>> people don't use them and that bash is what everyone does use, more
>>> or less.
>>>
>>> Bombadil
>>
>> I don't agree, people either are willing to run a solution in script
>> form or not (either taking time to figure if it's safe or not). I
>> don't see the problem, but it would take only a minute to recode that
>> in bash if you prefer, so maybe do that?
>>
> In order recode scripts you have to know BOTH languages.
Right, at least to the point where you know what it's doing and how to
do that in the different language. So, you don't have to know the
other any better than to understand what it's doing.
> I am not
> learning a new language in order to recode a snippet. Are you nuts?
Okay, relax. I never suggested you learn a new language and what I said
wasn't crazy. I said, if you know bash (which is what you apparently),
then you will quickly recognize what the tclshell script is doing and
be able to make a few small and quick changes for valid, working bash
code.
> In response to your other article, bash is _by_far_ the most commonly
> used scripting language in linux. People who post solutions in
> (relatively) obscure scripting languages on general linux forums
> are being elistist jerks.
>
> Bombadil
You've got a pretty strange attitude here about what you insist upon,
when you don't seem to know a lot. After all, you ripped into someone
that replied and offered code to help you. You complained, said you
were joking and then complained in every post following it. No one is
insisting you use the code. If you don't want to, I don't think anyone
is going to be upset. Also, korn shell and Perl are not obscure in any
manner, nor is tcl scripting.
Bombadil
Wrong. I don't understand the code there. This should be quite obvious
to you.
Assuming that because a person knows one scripting language that they can
use another is quite erroneous.
You are far too relaxed. Get some exercise and some oxygen to your
brain.
>> In response to your other article, bash is _by_far_ the most commonly
>> used scripting language in linux. People who post solutions in
>> (relatively) obscure scripting languages on general linux forums
>> are being elistist jerks.
>>
>> Bombadil
>
> You've got a pretty strange attitude here about what you insist upon,
> when you don't seem to know a lot.
You've got a strange attitude for someone who doesn't seem to know a lot.
> After all, you ripped into someone
> that replied and offered code to help you.
No. I ripped into someone who was trying to impress everyone with
his technical superiority by posting an alleged solution in a scripting language
that only a tiny percentage of linux users use.
And the jerk didn't even commment the code.
> You complained, said you
> were joking and then complained in every post following it. No one is
> insisting you use the code.
Nor did I ever imagine that I had to. Nor say so.
Who are you talking to?
> If you don't want to, I don't think anyone
> is going to be upset. Also, korn shell and Perl are not obscure in any
> manner,
I never mentioned korn. Once again I ask: Who are you talking to?
> nor is tcl scripting.
For every person who knows tcl, there are a thousand who know bash.
What language would you use to post a solution on a general linux
forum?
Apparently, any language that popped into your head.
Remind me to be very careful about taking any technical advice from you in
the future.
Bombadil
Nathan Keel
Yes, it is obvious you don't know the code, which is why you said what
you did. But, the thing I was saying, is how is bash any better for
you? If you knew any bash at all, you'd be able to understand the
tclsh code immediately (it's very close). I'm not upset that you don't
know it (or want to), I just was confused that you were complaining
that it wasn't in bash (since the fact you don't understand the posted
code, shows you don't know bash either). I don't mean that as
offensive, I just am saying that's what I found confusing.
> Assuming that because a person knows one scripting language that they
> can use another is quite erroneous.
Not when they are almost the same in the example.
> You are far too relaxed. Get some exercise and some oxygen to your
> brain.
Don't be an asshole because you are so picky and choosy about the help
people give you (for free). I wasn't insulting you, I was genuinely
confused. Also, the last thing anyone would accuse me of, is being too
relaxed.
>>> In response to your other article, bash is _by_far_ the most
>>> commonly
>>> used scripting language in linux. People who post solutions in
>>> (relatively) obscure scripting languages on general linux forums
>>> are being elistist jerks.
>>>
>>> Bombadil
>>
>> You've got a pretty strange attitude here about what you insist upon,
>> when you don't seem to know a lot.
>
> You've got a strange attitude for someone who doesn't seem to know a
> lot.
That's the best you can do? You're upset at yourself, not me.
>> After all, you ripped into someone
>> that replied and offered code to help you.
>
> No. I ripped into someone who was trying to impress everyone with
> his technical superiority by posting an alleged solution in a
> scripting language that only a tiny percentage of linux users use.
You're being ridiculous and petty. The person didn't post what they did
to try and impress anyone, it was to help you. They posted what they
knew, and maybe they didn't have the script in bash? As for technical
superiority, the script was very basic and simple, I don't think the
guy posted it to show off or boast. Is that the reaction people get if
their helpful replies don't meet your very specific and limited
knowledge or comprehension and demanding attitude? If you're going to
be so offended when someone offers help, don't ask for help. Now
you're just being weird. As for the percentage of Linux users, you
clearly don't know much about this field, and you are comfortable
proclaiming things you feel (based on you personally not knowing) as
fact. That's taking it a little too far. It's used enough, even if
it's not as common as bash. It's the solution they knew, in the
language they knew and they offered their code and time to you for
free, not showing off, not asking for anything, and instead of thanking
them, you rip into them, and then rip into me when I said how it's
confusing you insist on bash when if you knew bash well enough to
matter which script you ran (bash or tlcsh) that you'd see if it was
safe or familiar.
> And the jerk didn't even commment the code.
Consider that you might be the jerk in this situation. Maybe let it go?
>> You complained, said you
>> were joking and then complained in every post following it. No one
>> is insisting you use the code.
>
> Nor did I ever imagine that I had to. Nor say so.
Then what's the problem? Why are you still complaining and insulting
people about it? Move on.
> Who are you talking to?
To you, obviously.
>> If you don't want to, I don't think anyone
>> is going to be upset. Also, korn shell and Perl are not obscure in
>> any manner,
>
> I never mentioned korn. Once again I ask: Who are you talking to?
I mentioned korn shell and Perl are also very common in response to you
claiming almost everyone used bash for almost everything on Linux. I
outlined this wasn't the case. You replied to that and went on about
obscure languages. I said those aren't. I was talking to you.
>> nor is tcl scripting.
>
> For every person who knows tcl, there are a thousand who know bash.
Maybe, maybe not. Where do you get your figures?
> What language would you use to post a solution on a general linux
> forum?
That depends on the question, what I know and what's more appropriate.
It's not always bash. I could post bash and Perl and korn shell
scripts you'd be just as confused about and offer a script in each
language and that would just just as unhelpful to you.
> Apparently, any language that popped into your head.
Not really, as explained above. You can assume the poster intentionally
tried to confuse you by posting a solution in a language that
apparently they somehow knew you didn't know if you like, but I think
your attitude sucks.
> Remind me to be very careful about taking any technical advice from
> you in the future.
>
> Bombadil
Remind me (and everyone else) not to bother to try and offer any help to
your ungrateful, clueless ass in the future.
Harold Stevens
> your ungrateful, clueless ass in the future
Looks like Hardon Quack got himself quite the nervy sockpuppetry going.
--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at airmail, dotted with net. DO NOT SPAM IT.
I toss GoogleGroup posts from gitgo (http://improve-usenet.org).
Bombadil
> In <_wnMl.29772$5N7....@newsfe09.iad> Nathan Keel:
>
>> your ungrateful, clueless ass in the future
Well, I guess the arrogant technocrats gotta stick together.
> Looks like Hardon Quack got himself quite the nervy sockpuppetry going.
Don't know the name, but I'll be on the alert for it.
Bombadil
Nathan Keel
> In <_wnMl.29772$5N7....@newsfe09.iad> Nathan Keel:
>
>> your ungrateful, clueless ass in the future
>
> Looks like Hardon Quack got himself quite the nervy sockpuppetry
> going.
>
I don't know who that is or if they are being a sockpuppet (I was just
accused of this in another forum myself and it wasn't true, so I
hesitate to accuse others), but the person has a chip on their shoulder
and aren't winning any points either way. :)
Nathan Keel
> Harold Stevens <woo...@aces.localdomain> wrote:
>> In <_wnMl.29772$5N7....@newsfe09.iad> Nathan Keel:
>>
>>> your ungrateful, clueless ass in the future
>
> Well, I guess the arrogant technocrats gotta stick together.
Man, you're got problems. If you annoy people attempting to help you,
you aren't going to win points. If you don't care about that, stop
dragging it out.
>> Looks like Hardon Quack got himself quite the nervy sockpuppetry
>> going.
>
> Don't know the name, but I'll be on the alert for it.
Why? Apparently they think and act like you?
Bombadil
> Bombadil wrote:
>
>> Harold Stevens <woo...@aces.localdomain> wrote:
>>> In <_wnMl.29772$5N7....@newsfe09.iad> Nathan Keel:
>>>
>>>> your ungrateful, clueless ass in the future
>>
>> Well, I guess the arrogant technocrats gotta stick together.
>
> Man, you're got problems. If you annoy people attempting to help you,
> you aren't going to win points.
> If you don't care about that, stop
> dragging it out.
Except that you are the one "dragging it out", obviously. Do you
ever pull your head out of your ass and look at the real world?
If you did, you would notice a few simple facts:
I do not take orders from you and I don't want your bad advice
and I don't want to "win points" with you.
I disagree with you. If you don't like it you can fuck yourself
with something dirty and jagged.
Bombadil
Nathan Keel
> Nathan Keel <na...@gm.ml> wrote:
>> Bombadil wrote:
>>
>>> Harold Stevens <woo...@aces.localdomain> wrote:
>>>> In <_wnMl.29772$5N7....@newsfe09.iad> Nathan Keel:
>>>>
>>>>> your ungrateful, clueless ass in the future
>>>
>>> Well, I guess the arrogant technocrats gotta stick together.
>>
>> Man, you're got problems. If you annoy people attempting to help
>> you, you aren't going to win points.
>> If you don't care about that, stop
>> dragging it out.
>
> Except that you are the one "dragging it out", obviously.
There's nothing "obvious" about you accusing me of dragging it out,
because I'm replying to you, except the obvious trolling you're doing.
> Do you
> ever pull your head out of your ass and look at the real world?
Spoken like a true moron. You are upset because you don't know bash or
tclsh, and you're taking it out on everyone else. That's pathetic.
> If you did, you would notice a few simple facts:
> I do not take orders from you
Perhaps you should notice that none of us here take orders from you
either. After all, you're the one that's upset and whining that the
person whom offered you help didn't comply to your specific
requirements (based on the fact that you're clueless about shell
scripts).
> and I don't want your bad advice
I didn't offer you any advise. I pointed out that you're being
unreasonable for getting worked up, complaining about and being
ungreatful because YOU don't understand the script someone posted to
help you. What sort of asshole takes someone's attempt to help them so
personally?
> and I don't want to "win points" with you.
I don't think there's any threat of that happening.
> I disagree with you.
There's nothing to disagree about.
> If you don't like it you can fuck yourself
> with something dirty and jagged.
>
> Bombadil
Are you coming on to me?
Harold Stevens
[Snip...]
> Are you coming on to me?
That would certainly be consistent with Hardon Quack's style.
Maxwell Lol
>> It might already be installed though. Tcl is commonly used by a number
>> of packages.
>
> Don't have it. That should be obvious to you.
No - it's not obvious. You might just not have bothereds to check,
especially if you are lazy.
>
>> The above code was just an example of how to create a 'reverse lookup'
>> using ldd itself. Feel free to re-code it in the scripting language of
>> your choice.
>
> And how I am supposed to do that when I don't understand the scripting
> language you used and it isn't even commented?
>
> Uncommented code is the sign of an amateur or an incompetent, especially
> in a situation like this.
I don't know tcl, but I am willing to look at it and guess.
> > set bins {}
> > foreach p [split $::env(PATH) :] {
> > lappend bins [file join $p *]
> > }
Well, gee - it looks like it does something with the PATH variable.
There is an append functiuon. Perhaps it adds directories from the
searchpath to the "bins" variable?
> >
> > foreach f [eval [list glob -nocomplain] $bins] {
> > if {[catch {exec ldd $f | grep -q [lindex $argv 0]}]} {continue}
> > puts $f
> > }
There's a foreach so it's a loop, and it looks at directories in the
"bins" directory.
Then there is a ldd, and a grep.
So I am guessing it does a ldd and grep for each file in the
searchpath. And it says $argv, so perhaps it's grepping for a command
line argument.
....and I don't know or use tcl. And I didn't look at a manual.
So I have to wonder what you really want. Someone gave an answer that
works, and you insulted the author for posting working code that you
don't understand, and are too lazy to try to figure out, that I was
able to after just a few minutes of thinking.
It's a good thing we have killfiles.