gcmd-devel
[Top][All Lists]
Advanced

[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°





reply via email to

[Prev in Thread] Current Thread [Next in Thread]