[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gcmd-dev] finding files
From: |
Michael |
Subject: |
[gcmd-dev] finding files |
Date: |
Tue, 29 Jan 2008 16:43:03 +0100 |
User-agent: |
claws-mail.org |
Aye, it's not too hard to have to type additional "cd " given that gcmd now
spares the space for extra address field, and that you can do magic with a
commandline.
Hmm...there is a commandline history (ALT+F8) but there's no filename
completion, no ? I like this feature in KDE apps, maybe Gnome has it too
already (not checked.)
Apropos magic.
I can't the heck find out how to use xargs to cd into a distant folder when i
don't want to type the full path (because it's very long or i just forgot the
spelling):
~/READER mi: pwd
/home/micha/READER
~/READER mi: find -name Ecuad*
./REISEN/Ecuador
~/READER mi: cd ./REISEN/Ecuador
~/READER/REISEN/Ecuador mi:
but
~/READER mi: find -name Ecuad* | xargs cd
xargs: cd: No such file or directory
I have to fall back to crude backticks like
~/READER mi: cd `find -name Ecuad*`
which however doesn't work in gcmd, as well as
cd $(find -name Ecuad*)
...is this a safety feature ?
Luckily we have Alt+F7 'find file'.
And here is my proposal:
(1) Find file appears to me to belong under the 'File' menu, at least that's
where i always look first.
(2) m°ntuitively (tm) i feel that double-clicking on a hit entry would do
'goto' that file or folder. I would have to say 'Open' explicitly via button
(thus, the button and click functionality exactly exchanged) because that's a
little bit mission critical (executables, very huge files...yes, i _have_ 1G
images...) and more safe this way - it can not be mistaken.
Heh, some people are never satisfied no ?
(Skip the following, it's just a long useless pleading)
I'm using filesystem as database, maintaining enourmous complex and stunning
intelligent sorted folder trees which allow me to find any piece of media or
information really fast, and prevents me to depend on anything else (for
example, it would work even on a ssh terminal). I think it's exactly the usage
filesystems are developed for, and it makes not too much sense to me to create
virtual databases (like image or music 'Collections') which finally end up
stored on disk with nearly the same I/O, and usually binding me to a specific
app. Where 'pure filesystem' allows me to interchange between different
Operating Systems (for example, copying on external drive or through network)
without any information loss, and backups will probably be readable way in the
future too.
People tend to argue disk operations are slow (where a real database does what
instead ??) but this argument is getting obsolete soon, with modern filesystems
and hardware.
SATA 7200rpm is horribly fast already, theoretically 3Gbit/s which hopefully
equals 375M/s throughput, and with port multiplier even 6Gbit/s.
And soon we'll see Ram drives (Solid State Drive) of several hundred G. MacBook
Air has 64G that's just a beginning.
Where we enter funny speeds up to theoretically 25 G/s (according to
http://en.wikipedia.org/wiki/List_of_device_bandwidths#Memory_Interconnect_Buses_.2F_RAM
)
which will stop the discussion somehow.
I think we could imagine filemanagers like a SQL database GUI, to get a feeling
where it could go. It's main usage will always be finding data, and present it
sorted after any criteria we can think of.
m°