Why was "which" command removed in 1.0.7?

[~newbie]

why was "which" command remove in 1.0.7? i use this command to verify if i have installed the program correctly...

e.g.

Code: Select all

# which scalc
/usr/local/bin/

[Guest]

# cat /etc/puppyversion
107
#
# which which
/usr/bin/which
#

[jmarsden]

why was "which" command remove in 1.0.7?

It is there in my copy of 1.0.7

If you truly lack it, or just want to try an alternative, you can use the bash shell builtin type instead (assuming that you are typing commands into a default bash shell, or running a bash shell script). Examples might be:

Code: Select all

21:55:07 root@jm:~# which echo
/bin/echo
21:55:09 root@jm:~# type -a echo
echo is a shell builtin
echo is /bin/echo
21:55:13 root@jm:~# 

For more info:

Code: Select all

21:55:13 root@jm:~# help type
type: type [-afptP] name [name ...]
    For each NAME, indicate how it would be interpreted if used as a
    command name.
    
    If the -t option is used, `type' outputs a single word which is one of
    `alias', `keyword', `function', `builtin', `file' or `', if NAME is an
    alias, shell reserved word, shell function, shell builtin, disk file,
    or unfound, respectively.
    
    If the -p flag is used, `type' either returns the name of the disk
    file that would be executed, or nothing if `type -t NAME' would not
    return `file'.
    
    If the -a flag is used, `type' displays all of the places that contain
    an executable named `file'.  This includes aliases, builtins, and
    functions, if and only if the -p flag is not also used.
    
    The -f flag suppresses shell function lookup.
    
    The -P flag forces a PATH search for each NAME, even if it is an alias,
    builtin, or function, and returns the name of the disk file that would
    be executed.

That should be more than enough info on this subject, I think!

Jonathan

[kethd]

I often find things this way:
# du -a / | grep sysinit
Being new to the command line, I am just learning, but this is a very powerful and useful way to look everywhere for something.

But you have to remember that Linux is case sensitive. So if you are looking for stuff related to Gdmap, you might be safer trying
# du -a / | grep dmap

[MU]

in any case it should be in /.usr_cram/bin
If it was deleted for any reason from /usr/bin, you can copy it over.

Mark

[jmarsden]

I often find things this way:
# du -a / | grep sysinit
Being new to the command line, I am just learning, but this is a very powerful and useful way to look everywhere for something.

This finds stuff anywhere, in your $PATH or otherwise, by scanning the entire filesystem, computing the size of every file, and then discarding the output for all lines not matching your string. It works, but is inefficient (slow on systems with large amounts of files).

If you are on a conventional Linux install on HD, the locate command is what you use to quickly find (locate!) files anywhere in the system whose names match a supplied substring. But this depends on a database of file locations being maintained by a periodic (usually nightly) cron job. Not often relevant on a CD-booted Puppy workstation.

If you want to find things by directly searching the filesystem, it is likely to be more efficient (and easier to remember?) to use ... wait for it ... the find command

Code: Select all

# find / -name "*sysinit*"

is one example. If you know what you seek is a regular file, adding -type f will also further speed the search. find is very powerful, worth learning. Check http://www.linuxcommand.org/man_pages/find1.html for an HTML-ized online man page for it.

But you have to remember that Linux is case sensitive. So if you are looking for stuff related to Gdmap, you might be safer trying
# du -a / | grep dmap

I suggest that it is more appropriate to use the relevant options to your search tool(s). For example: grep has a -i option for case-insensitive string matching, find has a -iname option for case-insensitive filename matching. So, you might try

Code: Select all

# du -a / |grep -i gdmap

Better still, I suggest, would be to try

Code: Select all

# find / -type f -iname "*gdmap*"

instead, to look for all normal files whose names contain gdmap or Gdmap or GdMap or even gDmAp.

However, to be clear: kethd has changed the topic of the thread somewhat here, perhaps accidentally! This new subject (finding files anywhere in any mounted filesystem) is a very different thing from finding out where commands in your $PATH are, or whether those commands are external or bash builtins etc. (which is what was being discussed earlier, using which and type).

Jonathan

[kethd]

Jonathan,
Thanks for all those great tips!
Yes, it all depends on what kind of an install you are using. I know that my grep way is the most inefficient use of the machine. But if I am on a fast RAM/CF-IDE system and it only takes 3 seconds total, it is much more efficient than typing a longer command, of my time. On a more practical level, it takes a long time to get comfortable with all the switches for all the commands. There seems little rhyme or reason to them. And, for example, the du option I most want, --max-depth=1, seems to have no standard usable practical shortform! (Yes, I know there are all kinds of ways I can "customize" the command line. But I don't want to get addicted to me own weird ways of doing things, and not be comfortable with the generic default standard. Any recommendations on the best, most "standard" packages of shortcuts/aliases/macros etc for making the command line more efficient?)

The first thing that bit me getting used to the Linux command line was the shock of discovering how much was being hidden from me. Because of the leading period and because of the case-sensitivity. So as a newbie I have grabbed the life preserver of the one most powerful command I could find that would really show me Everything...

I consider this all a learning/training excercise. We are blessed to learn on a Little Linux, where we can do things the wrong way and not suffer too much. And maybe gradually learn how to do things the right way, so that we can support Big Serious Linux systems, someday, should the need arise.

[jmarsden]

But if I am on a fast RAM/CF-IDE system and it only takes 3 seconds total, it is much more efficient than typing a longer command, of my time.

So make yourself an alias or shell function in your ~/.bashrc file, and copy that file to every machine you have shell access to. Over time, your .bashrc will change grow to meet your own changing needs.

On a more practical level, it takes a long time to get comfortable with all the switches for all the commands. There seems little rhyme or reason to them.

Sad but true. Just like learning to spell in English, really! Yet may people consider learning to spell a useful subset of English words worth doing, if they expect to do a fair bit of writing in English during their lifetime. Similarly, may I suggest that learning a useful subset of Unix commands and switches is also worth doing, if you expect to spend a fair bit of time using Unix (or Unix-like shells) in your lifetime!

And, for example, the du option I most want, --max-depth=1, seems to have no standard usable practical shortform!

That option seems to me to make du close to useless... why not just use ls, if all you need is a list of what is in one directory and how big each item is??

(Yes, I know there are all kinds of ways I can "customize" the command line. But I don't want to get addicted to me own weird ways of doing things, and not be comfortable with the generic default standard. Any recommendations on the best, most "standard" packages of shortcuts/aliases/macros etc for making the command line more efficient?)

Your own package, because it is tailored to only including the things *you* need My own .bashrc works fine on a wide variety of machines, from RedHat to SuSe to Fedora to Puppy to DSL to FreeBSD to NetBSD to even SCO and Novell commercial Unices, and SGI Irix (though it's been a while, I might have accidentally broken compatibility with some or all of the commercial ones by now!). I strongly suggest that you do *not* use someone else's package of shell customizations. It won't be what you need, and you won't learn from the process of creating it. By all means read one or two, and make notes of the kinds of things they offer, and if you see useful shell coding ideas you like, "borrow" those ideas. But don't just use such a package.

Of course, to have maximum shell compatibility you *could* use only the sh-compatible subset of bash's capabilities, and keep all your customizations in ~/.profile But I think that's losing out on a few nice bash enhancements that (for me) are worth the small loss of portability. I have not worked on a machine that did not have bash and on which I also could not download, build and install bash, for ... a long time!

The first thing that bit me getting used to the Linux command line was the shock of discovering how much was being hidden from me. Because of the leading period and because of the case-sensitivity.

That's a peculiar perception, really. You have access to so much power and so many capabilities at the shell prompt, it is almost overwhelming. For example, here's what happens when I hit the TAB key twice in bash on my FC4 PC (nothing special, a couple of years old generic P4 box)

Code: Select all

01:08:50 jonathan@jm:~$
Display all 3432 possibilities? (y or n)
01:08:50 jonathan@jm:~$

So, I have 3432 commands available to me, right there! And that's probably not a particularly high number for a normal Linux box. I even have a few more than that on the (Cygwin) bash shell on our family's one Windows PC ( a small concession to requirements the local university has for some of my son's courses, I'd prefer a Microsoft-free household) -- 3857 over there.

So as a newbie I have grabbed the life preserver of the one most powerful command I could find that would really show me Everything...

That would be

Code: Select all

# find /

I suppose Yet even that doesn't show you shell aliases and functions, nor shell variables -- there is still more out there, ready for when you need it. And that is the key. Learn as much as you need to do what you want or need to do with your computer(s), as fast as you need to learn those things. It's very much OK if you end up doing things in unusual ways at first, as long as you transition towards accepted good practice as you become more proficient. It's really hard to kill anyone by typing something at a shell prompt on any PC you are likely to have access to, so learning by doing is possible and appropriate. Reading a few suitable tutorials and guides might speed the process along, too, for many users.

Jonathan

[kethd]

"And, for example, the du option I most want, --max-depth=1, seems to have no standard usable practical shortform!"
That option seems to me to make du close to useless... why not just use ls, if all you need is a list of what is in one directory and how big each item is??

Because, as far as I know, ls won't show me the size of directories -- which is the main thing I want.

Typically, I want to see simply on one screen a summary of all space usage by a folder (including it's subfolders). If I look at more than one level at once, it is likely to be confusing and/or scroll off the top of the screen. If I can just get a complete summary at the top-current level, and then easily drill down into the fattest directories and do the same thing, I can quickly get a handle on the main space consumers. If there is a better/quicker/simpler way to do this from a plain-vanilla CL than using du --max-depth=1, please tell me!

(Is there a light-weight text-only tool similar to Xdiskusage, that will fit all the most important info about the largest files/folders on one screen, in some sort of tree format?)

Since my work right now is focused on systems like bare unconfigured LiveCDs (and troubleshooting failed sysinits) I am a ways from being able to have any personal mods always available from the command line.

I tried using the fancy TAB bash CL features on Puppy, but was unimpressed. On the filename completion, it seemed weird that it would give me the choices, but there seemed to be no way to just pick one -- I just had to keep typing the filename until I reached uniqueness. And none of the other TAB features seemed to work in Puppy. Maybe I made a wrong turn somewhere -- is TAB access to commands etc in Puppy?

[jmarsden]

... why not just use ls, if all you need is a list of what is in one directory and how big each item is??

Because, as far as I know, ls won't show me the size of directories -- which is the main thing I want. ... If I can just get a complete summary at the top-current level ...

I use:

Code: Select all

# du -sm *

(Is there a light-weight text-only tool similar to Xdiskusage, that will fit all the most important info about the largest files/folders on one screen, in some sort of tree format?)

I'm not sure about tree format, but something like

Code: Select all

# du -a . |sort -nr |head

would give you a "top ten big things at or below the current directory" list, biggest first... is that close to what you seek? Or

Code: Select all

# du -as * |sort -nr |head

to add in the "summarize at this directory level" concept you seem to prefer. In general, I urge you to use the Unix tools philosophy: build the special purpose tools you need by stringing together existing simple tools with pipes You can build them temporarily at the command line itself (using command history to re-access them as needed), or turn them into small shell scripts or aliases or shell functions.

Since my work right now is focused on systems like bare unconfigured LiveCDs (and troubleshooting failed sysinits) I am a ways from being able to have any personal mods always available from the command line.

(a) If you can truly run Bash after a sysinit failure, you have an unusual setup -- tell me more! (b) Are you saying that you need a tool to look at disk space usage on an unconfigured LiveCD??? Surely in that context, you would already know what you put into the .iso before you even burned the CD? You have the tree of files from which you built the ISO sitting on your development box... use du over there, not on the test box you just booted the newly developed LiveCD on! (c) On any machine that has an Internet connection and ssh, a quick

Code: Select all

# scp -p me@mybox.mydomain.com:.bashrc .

is all it takes

I tried using the fancy TAB bash CL features on Puppy, but was unimpressed. On the filename completion, it seemed weird that it would give me the choices, but there seemed to be no way to just pick one -- I just had to keep typing the filename until I reached uniqueness.

That's by design. Why would you want to suddenly switch away from typing to some other mode of data entry? Keep your hands on the keyboard, stay focused... it's very productive once you are used to it. Also, it works on a huge variety of Unix-like machines all over the world.

And none of the other TAB features seemed to work in Puppy. Maybe I made a wrong turn somewhere -- is TAB access to commands etc in Puppy?

Yes. Bash is bash is bash. At least for me, command completion in bash under Puppy 1.0.7 "just works". Can you provide an example that fails for you in Puppy 1.0.7? Did you read the relevant sections of the Bash Reference Manual to check that what you expect by way of TAB capabilities is what Bash does out of the box? Which other shells that have TAB-based completion facilities are you comparing Bash to?

Jonathan

[GuestToo]

Is there a light-weight text-only tool similar to Xdiskusage

i think you would like my Xdu package ... it is a gui tool like xdiskuseage, and is exactly like xdiskuseage because it is the program that xdiskuseage was based on

at 14k, i think it could be called light-weight