Berawal dari baca postingan Istri saya disini, jadi terinspirasi membuat versi  grafisnya.

audiohacked has started a python library for the Bus Pirate. So far, it’s been tested as an EEPROM dumper:

I have started writing a python library for the bus pirate. It’s ugly and messy, but I was able to use it to dump the firmware from an SPI chip… You can contact me if you need more information.

The source code is available here.

Linux dapat dikendalikan oleh satu atau lebih interface baris perintah (command line interface atau CLI) berbasis teks, user interface grafis (graphical user interface atau GUI, yang umumnya merupakan konfigurasi bawaan untuk versi desktop).

Pada desktop, GNOME, KDE dan Xfce merupakan user interface yang paling populer, walaupun terdapat sejumlah varian user interface. Antarmuka pengguna yang paling populer berjalan di atas X Window System (X), yang menyediakan transparansi jaringan yang memperolehkan sebuah aplikasi grafis berjalan di atas satu mesin tetapi ditampilkan dan dikontrol di mesin yang lain.

GUI yang lain memiliki X window manager seperti FVWM, Enlightenment, Fluxbox dan Window Maker. Manajer jendela menyediakan kontrol untuk penempatan dan penampilan dari jendela-jendela aplikasi individual serta interaksi dengan sistem jendela X.

Sebuah sistem Linux umumnya menyediakan sebuah command line interface lewat sebuah shell, yang merupakan cara tradisional untuk berinteraksi dengan sebuah sistem Unix. Sebuah distro Linux yang dikhususkan untuk lingkungan peladen mungkin hanya memiliki CLI sebagai satu-satunya interface. Sebuah sistem yang tidak memiliki monitor hanya dapat dikontrol melalui command line lewat protokol seperti SSH atau telnet.

Kebanyakan komponen tingkat rendah Linux, termasuk GNU Userland, menggunakan CLI secara ekslusif. CLI cocok untuk digunakan pada lingkungan otomasi tugas-tugas yang repetitif atau tertunda, dan menyediakan komunikasi inter-proses yang sangat sederhana. Sebuah program emulator terminal grafis sering digunakan untuk mengakses CLI dari sebuah Linux desktop.

php 4.3.0 have CLI(command line interface) On by default. Today I am going to say about how to run php by command line in windows.

First of all you need to go to the php folder in your xampp by cmd. If you use svn, then you will have an error saying “Unable to load dynamic library ‘E:/xampp/php/ext/php_svn.dll’- the specified module could not be found”.

To solve this problem, you need to copy to following files from Apache/bin/ to php/ :

libdb43.dll
intl3_svn.dll
libapr.dll
libapriconv.dll
libaprutil.dll

These will solve the above problem.

Now to execute a php file write the command: php address_of_the_file_to_run(for example E:/xampp/htdocs/tab.php)

you can pass arguments in the command line.And one the server side, you can fetch the argument by the $argv variable, the first element is always the filename that is executing.

An act of encouragement: if you feel this site is helpful,then please click on of the ads as an act of encouragement.Thank you for your encouragements.

Umzug nach www.derPathfinder.de

BadPoetry WordPress 2.7 has just been released and features a complete interface overhaul. Hack a Day runs on WordPress MU hosted by WordPress.com, so we got this update last week. We run standard WordPress.org on all of our personal blogs though. We recommend it because it’s free, has a massive userbase, and if you host it yourself, you can do whatever you want with it.

To make the upgrade process as simple as possible (and for the sheer rush of ‘rm -rf’), we use a one line command.

$ curl http://wordpress.org/latest.zip -o "wp.zip" && unzip wp.zip && rm -rf ./wordpress/wp-content/ && cp -r ./wordpress/* ~/www/

curl downloads the latest version from wordpress. unzip unpacks all of the files into a directory called ‘wordpress’. rm -rf removes everything in the ‘wp-content’ directory. Otherwise, you will overwrite your images, themes, and plugins. cp -r copies everything to your http document root, overwriting the previous install.

Naturally, you should back up your current install and database beforehand. We tend to use the one-liner with reckless abandon. If you’re wondering about the terseness, it was designed to fit inside the 140 character limit of Twitter.

[Thanks, Chris Finke]

#1 New MacBook © Mikael Miettinen

And there it is.

Wow.

I mean, it’s a truly beautiful piece of aluminium

And to christen this new family member… let’s unveil a useful command! Suppose you’re about to install some package you’ve found on the net. A classic .dmg mac file. Should you go for the graphical installer or for the command line interface? If I were to do it remotely, I’d choose the second! Then “hdid” is the command you are in need of!

Launched on a terminal, “hdid” will mount a .dmg file in the /Volumes directory. Of course we can override this behaviour (and that’s what’s the “hdid” man page for!). By the way of illustration:
$ hdid sample_package.dmg
(Also known as working: $ hdiutil attach sample_package.dmg)

With just “hdid” we’re only halfway to the finish: in particular, we need to run the “installer” command (as root, or more precisely, as root through “sudo”) on the package we can find in the /Volumes directory (usually ending with .pkg). Let’s continue with our little example:
$ sudo /usr/bin/installer -pkg /Volumes/sample_dir/sample_package.pkg -target /

Last step, there is nothing left for us to do but umount the mounted package:
$ hditutil detach /Volumes/sample_dir/

And that’s it.

In the previous Future Storage System articles, we’ve covered the basic hardware foundation for what I envision to be a powerful future-oriented storage solution for the commercial midrange.  However, as you’re probably aware, hardware is meaningless without software to provide the operational capabilities that are needed to mange information.  In this article, I will focus on a general design for an extensible software layer (an OS) that will provide future-oriented capability expansion as well as robust analytics, capabilities, and integration with business continuity principles.  As always, please reference the diagram below.

Future Storage System - Operating System - Conceptual

I will review this diagram starting from the upper right hand corner and will drill down on each bullet point made.  Again, as these ideas are further developed, I’ll probably move to a more classic diagram via Visio or something similar, but, for now this will have to suffice. You should see my whiteboard right now.

Core:

When discussing the core of the operating system, I have to be somewhat ambiguous, namely, the underlying kernel technology will dictate the inherent flexibility of the design. I will be honest in that I believe a hypervisor-based model (a la VMWare, Xen, et al.) will enable more features and flexibility than a bare-metal OS with a direct kernel/HAL relationship.  Additionally, as we move further into the features and functionality of this FSS OS, this hypervisor building model will become extremely important.  I’ll reserve details on that for another post.

Getting back to the subject at hand, I’ve divide the “Core” section into 4 basic sections: Drivers, I/O Engine, Hypervisor (?), and Management (Base). Let’s discuss the roles of each of these.

• Drivers.  This particular aspect of the Core OS deals with how the hardware interfaces with the OS itself.  This can be either a generic driver model (a la VMWare) or can be manufacturer specific and developed/maintained (a la Hyper-V).  There are advantages to both approaches;  with generic driver models, you get away from havoc-causing revisions to driver stacks or resource models that can (and are) introduced on a regular basis.  By standardizing on a generic driver model, you can also set specific boundaries around drivers for QA purposes and keep your overall OS implentation “clean.”  With specific driver models, you reap the benefits of core optimizations made by the manufacturer. This adds to the overall performance envelope of the underlying hardware technology as it relates to the OS layer. It obviously introduces some level of risk to the OS in that driver refreshes could theoretically “break” existing connections or the OS itself, but this could be mitigated by extensive modeling and alpha/beta programs.
• I/O Engine. Again, talking in theoretics here, the I/O engine encompasses the basic storage functions for the OS.  This could be broken out into Data Protection Algorithms (i.e RAID) and Encode/Decode functions for passing data to/from cache and disk.
• Hypervisor.  As stated in the start of this section, the model I’m embracing is a hypervisor-based one that allows for functionality and features to be “plugged in” through software and hardware (don’t forget Torrenza!!!).
• Management (Base).  This management function relates to the capabilities of the FSS operator to accomplish basic tasks through a GUI or CLI interface.  It would involve RAID/Storage group creation, host assignment, registration & configuration, and other basic tasks that are typically accomplished.  As noted in the hardware overiew of Part 2, there would be a dedicated management port (GigE) designed to handle interaction.

Extended:

When discussing the extended section of the OS, I’m referring to features that extend the native capabilities of the OS as installed.  This section deals with building out the OS to cover such features as Thin (virtual) Provisioning, System Analytics, Quality of Services features, and DeDuplication.  I’ve kept this list to four major categories but I do assume that there could be other technologies that emerge that will add to this list.

• Thin (Virtual) Provisioning. Call it “thin,” call it “virtual,” it doesn’t matter.  Companies (and people) that get caught up in semantics really have better things to do with their time (like actually implementing hardware FC, not software emulation) .  Essentially, Thin Provisioning allows the Future Storage System to manage information growth by only allocating storage that is needed versus what is wanted.  By spoofing the storage size to the attached hosts, you’re able to better handle growth and storage utilization (important when you’re already dealing with usable capacities below 50%).
• System Analytics. Included in the Core OS is a base level of analytics, equivalent to the SysInfo command you could run on a typical Microsoft or VMWare OS.  By including this from the start, most customers would be able to report on their hardware/software frameworks and determine if there were any failures.  Beyond this basic level of reporting, there often arises the need to determine what is happening from a hardware standpoint, i.e. Processor load, RAID Group response time, etc.  The System Analytics extension would provide in-depth reporting facilities to “fine tune” particular aspects of the FSS.
• Quality of Service. Similar in approach to DRS-enabled clusters within the VMWare environment (where you can assign resource “shares” across several different slices of physical hardware), the QoS features of the FSS would allow RAID Group or LUN level performancing based on policies (covered in the “Specialized” Section below) in addition to potentially handing vNIC (IP, iSCSI, FCoE?) or vPORT (FC) splitting and throttling for bandwidth.  Current storage system implement similar features at the LUN level or RAID Group level only; the extension of QoS to the port level on the storage system itself is rather unique.
• Deduplication.  There’s no doubt about it; whether we’re talking about NetApp’s ASIS or EMC’s Avamar, data deduplication is a feature that is here to stay.  The affects of deduplication may not be obvious at first but, over the lifespan of your data, it will enable quicker backups and replication in addition to increasing storage efficiency on your storage system.  Not much else to say about this particular technology for now, but, suffice it to say, as an extension to the Core OS, it can be a powerful tool.

Specialized:

Outside of the Extended features that could be “plugged in” to the Core framework, I determined that there might be a few more specialized tasks that would require extra integration from either 3rd party resources or just additional developmental work beyond the norm.  In this particular category, I’ve put In-Band/Out-of-Band (Data at Rest) Data Encryption and Policies (Spindown, Power Management).  Let’s dive into these for a moment.

• Data Encryption.  With compliance laws (PCI, HIPAA, DoD, et al) becoming more and more de rigueur in storage and communication, it almost seems that Data Encryption should be a Core component versus an add on.  Nevertheless, it’s important to recognize that you need to be able to accomplish Data Encryption (and Decryption) on resting data and on data that is being processed for storage.  If anything, this is a perfect use case for Torrenza pluggables.   Standardizing encrytion on the FSS also means that you’ll need to have some level of “hooks” to the Core engine.
• Policies.  Ah, Policy.  Everyone hates the word but doesn’t understand the importance of policy until they run into a policy-less situation.  In any case, the FSS policy add-on would be more akin to a scheduling engine for job processing, encrypt/decrypt, deduplication, tiering (storage tiering), etc.  It could assume responsibilities for power management as well, similar to the Dynamic Power Management (DPM) functions of VMWare. Whether this stays as an add on or moves to Core remains to be seen.

Business Continuity:

Business Continuity, like Data Deduplication, is a hot topic these days.  In my mind, Business Continuity encompasses not only Disaster Recovery metrics but also data management characteristics. To that end, I’ve broken this section into 3 distinct pieces: Remote replication, local replication, and tiering.

• Remote Replication. As the term states, this section is devoted to moving data from source FSS to target FSS.  The goal is ultimately data protection over any distance outside of the physical geography of the source array (i.e. New York City to New Jersey).  The mechanism for this replication would be either synchronous (acknowledged write commits from source/target arrays) or asynchronous (delayed ack from target array), depending on RPO/RTO SLAs.
• Local Replication. Local replication I view as being within the data center, NOC, or campus.  While the physical location might be removed somewhat, the communication would stay on dedicated high speed links (dark fibre, fibre connection, multi-fabric SAN, etc.).  Replication under these auspices would more than likely err on the side of synchronous but could be asynchronous as well.
• Tiering.  Before anyone objects, there is a method to my madness.  Typically, storage tiering would be slapped under the Extended or Specialized categories based on my diagram above.  However, think of it this way.  Moving low priority data from primary to secondary storage is a form of BC, isn’t it?  You’re moving, managing, and making available data under the auspices of a different SLA, potentially to different subsystems (i.e. Clariion to Centera), with different connectivity.  What if the Future Storage System could move data AND the communication channel from higher speed SSDs or mechanical disks on FCoE or IB to slower SATA drives using vNICs at GigE bandwidth levels?  That type of manipulation would obviously require some enormous computingcomputing capabilities (as well as potentially buffering to SSDs or high speed cache), but the end result could be completely managed data SLAs.

Closing Thoughts:

A lot to chew through on this article and I hope you’ll point out the flaws in my thinking.  For the next part, I probably will dive into the Core of the OS a bit more and see what technical underpinnings would work.

cheers,

Dave

Related articles by Zemanta

• SaaS Solutions for Remote Systems Management
• Business Continuity and Verizon Business Global Network Readiness
• Solid state, cloud storage on tap for a power-hungry 2008
• Open Source Hardware Management Software by Paragent
• eCos real-time OS makes short work of building a SAN appliance
• VMware chief says the OS is history
• Sun close to releasing xVM Server
• Venture-Funded Consultants at Security Innovation Show Companies How to Make Software Unbreakable
• The five biggest storage trends
• EMC targets SMBs, branch offices with new low-end storage
• Brocade unfurls FCoE roadmap
• Nexsan paints SAS green
• Witness the future of Brocade
• Vendors hype new Fibre Channel over Ethernet tech

Before Netscape was founded, building a consumer software application usually meant building a Windows (or DOS) application.  Windows had 85%+ desktop market share at the time and Web applications did not exist.  If you wanted to reach the masses, Windows was the only game in town.  Then Netscape showed the world the power of interconnectedness + open standards.  

Standards adopted by the Navigator browser like HTML/CSS allowed developers and designers to quickly and easily build information-based front-ends to databases.  In the past you may have purchased Microsoft Encarta on CD-ROM, but now you could visit Yahoo’s directory to find thousands of places where you could go to get so much more.  In the past, if you wanted access to news or email you probably had an AOL client for Windows with dial-up service.  Now, all of a sudden, you could get your news from CNN.com and your email from Yahoo! Mail courtesy of the same client through which you collected your encyclopedic information.  Even if you had a Macintosh or UNIX box sitting on your desk.  Unfortunately, dial-up connectivity and HTML/CSS meant that for applications (like Microsoft Excel, PowerPoint, interactive games, and instant messaging), you still needed standalone applications on your desktop.

The universal adoption of Javascript and XML (in major browsers) and cable modems (in the home) led to the widespread use of AJAX.  This finally allowed browser-based applications to deliver “good enough” application performance in the browser to compete with standalone applications.  Web office applications like Google Documents, web-based instant messaging sites like Meebo, and interactive maps like Google Maps offered performance comparable to standalone clients.  On the video side, the ubiquitous deployment of Flash and cable modems is what enabled YouTube.  Without the ubiquitous deployment of Flash in the browser, YouTube would have been a failure.  

If you wanted to develop consumer applications for the desktop computer before AJAX, you had to develop for Windows.  Now you need to develop for AJAX.  While Windows wasn’t necessarily the best OS, it was the most pervasive.  While you may be able to develop a better stand-alone web client that can do everything that AJAX can do and more (not hard), chances are that your client is not and will not be pervasive.  The only time it makes sense to develop a client is when you are doing something outside the browser security model — controlling PC hardware like a webcam or microphone, for example.  Or tracking a user’s surfing patterns and making recommendations.   

So what does all of this have to do with SMS?  While Apple is about to launch their developer platform for iPhone, it will capture a tiny fraction of the 3.3 billion mobile subscribers worldwide — even if Apple hits their goal of 10MM units sold by the end of 2008, that is a drop in the bucket compared to 2 billion SMS enabled handsets in the market today!  Potential mobile entrepreneurs would be well served by learning from the PC and web revolutions — build your service on the back of a ubiquitous technology.

The only ubiquitous technology on mobile phones today is SMS.  Yet, with the exception of Twitter, most firms are building solutions that are leveraging “superior” technology that lacks anything close to ubiquity.  That’s a big mistake.

Idea:  Build third party consumer services based entirely on SMS.

I will toss out a few ideas on how SMS might be leveraged, but I’m sure that there are much better ideas out there.  I would love to hear from you have any ideas or know of companies doing something interesting with SMS (in the comments or directly at mike [at] shv [dot] com).  

1.  SMS Groups.

Today, more people use SMS to communicate than web-based email.  SMS is already email and IM all in one, so let’s focus on a different component of communications… One significant source of web-based email traffic today is group mailing lists.  Yahoo! Groups, MSN Groups, Google Groups — these products are basically very simply systems to manage communications (often in email).  Twitter is going after the status-casting opportunity, but why not create an extremely simple SMS Groups product?

On registration, have users import their address books WITH mobile phone numbers.  Have them group their friends into “family”, “theguys”, “jacksfriends”, etc.  This weekend I went to the playground after I hit Starbucks with the kids.  It would have been great to be able to send an SMS to some number with “jacksfriends going to the playground now, see you there.”  Instead I had to call each person and have a discussion about the fact that I was taking the kids to the playground.  A simple groups product with a total focus on SMS could be very interesting.

2.  SMS as Command Line Interface (CLI) for the Web.

Back in the DOS days, you would ask your computer to do certain tasks with very specific commands from a command line interface.  Why not build a web services abstraction layer with short SMS commands and SMS delivery?  Once a user learns basic commands, she could use SMS to browse the web for content much as users previously used commands to browse a hard disk or control an application with DOS.

For example, we could aggregate information on local restaurants from various services through web services.  We would then allow users to invoke these services by training them on how to use very simple commands over SMS.  This approach is similar to what Google SMS does, but the idea is to do it for more than just Google search.  And to have a common SMS interface through which users could interact with the entire web.

I’m a big fan of Twitter and I would love to see much more innovation around SMS.  The iPhone is great and, as a consumer, I appreciate that Steve Jobs is pushing the industry to move forward.  But between today and the day when the iPhone is ubiquitous (if that day ever comes), SMS is a good place to start when thinking about building a mobile startup.

На днях на блоге PerryGeo обнаружил сей замечательный пост. Думаю, он актуален и для многих отечественных ГИС (и не только) пользователей. Поэтому, ниже предлагаю вольный перевод:

К сожалению, большинство пользователей ГИС довольно далеки от командной строки (CLI – command line interface). Порой, даже опытные пользователи, оказываясь один на один с командной строкой, испытывают шок. Насквозь оконные интерфейсы нынешних лидеров ГИС-рынка, облекающие любую операцию в ГУЕвую оболочку (GUI – graphical user interface), только способствуют этому (тех кто еще помнит как работать в командной строке ESRI Arc/Info уже называют “старая гвардия”). К тому же, у пользователей XP и Vista отсутствует доступ к командной строке DOS. У Linux-пользователей дела с этим обстоят по-лучше, но разница уже не так велика, по причине наступления таких дистрибутивов, как Ubuntu (с через чур ‘дружелюбным’ интерфейсом).
Так что же такого ужасного в командной строке? Почему считается, что командная строка сложнее графического интерфейса? Я пришел к выводу что в некоторых случаях все совсем наоборот – набрать что-то и получить назад ответ проще простого! К тому же, создается ощущение полного контроля за компьютером (что, на самом деле правда). Компьютер всегда выполняет только те приказания, которые вы ему даете, каким интерфейсом вы бы не пользовались (GUI или CLI). Вот только GUI не концентрируется на мелочах, поэтому, вам не обязательно точно знать что вы приказали компьютеру. Такая легкость дается ценой многих важных факторов. Судите сами:

• Автоматизация. Представьте, что вы осуществляете мониторинг данных, и должны обрабатывать их каждый час. Неужели вы будете сидеть за компьютером все 24 часа в сутки?
• Воспроизводимость. Как только я показываю кому-нибудь операцию, осуществляемую через командную строку, первое, что мне говорят (ну, или хотя бы думают) – “Командная строка – это слишком сложно”. Взгляните на следующую команду конвертации картинки из .tif формата в формат ERDAS .img (HFA):
  

  cd /data/images
  gdal_translate -of HFA aerial.tif aerial.tif.img

  Вы, вероятно, спросите, “А почему бы не воспользоваться графическим интерфейсом, Кликнуть пару кнопок, и получить результат”? Возможно, но повторите это для 2000 картинок. В командной строке вам надо набрать всего лишь:

  cd /data/images
  for i in *.tif; do
  gdal_translate -of HFA $i $i.img;
  done

• Протоколирование (документирование). В ГИС анализе нет ничего важнее чем документирование работы. Вообразите напряженные пять часов работы. Все уже должно быть готово к 2 часам… наконец, работа закончена, теперь нужен протокол работ – какие процедуры и методы, и как были применены. В CLI вы просто копируете команды из терминала, или смотрите историю введенных команд. Вы можете сохранить историю в простом текстовом файле, и спустя месяц, вновь повторить те же шаги. В GUI вам надо запомнить каждый клик, каждую вкладку, каждую опцию, каждое действие. Часто, это предполагает наличие каких-то дополнительных пояснений, скриншотов и т.п., которые, конечно же, автоматически не сохранялись. И, конечно же, когда на следующий день вдруг понадобиться выполнить те же действия, но на другом материале, ни о каком автоматизированном повторении работы и речи быть не может.
• Доступность. В командной строке используется простой “плоский” (plain) текст без форматирования. Вы можете распечатать его, и изучить по дороге на работу. Можете отправить его по электронной почте коллегам. Можете использовать cvs для отслеживания изменений. Вы можете передать большой объем информации без необходимости сидеть, и записывать каждую процедуру шаг за шагом, клик за кликом в графическом интерфейсе.
• Точность. Слишком часто бывает, что GUI-дизайнеры “перемудрили” с интерфейсом в приложении, считая что пользователю не нужно знать ничего кроме необходимого минимума. Проводя аналогию с машиной, можно сказать что вы садитесь за руль, поворачиваете ключ, давите на педаль и едете. И совершенно не заботитесь о том, что происходит под капотом. Но иногда бывает нужно выполнить специфическую процедуру, о которой дизайнеры GUI даже не догадывались. Интерфейс командной строки не связывает ваши руки (так как выполняет именно то, что вы говорите), он осуществляет более точное взаимодействие с компьютером, и гораздо более удобен при отладке сложной проблемы.

Так что не думайте что все окна содержат волшебную кнопку, нажав на которую будет сделана работа. Во многих случаях использование командной строки более эффективно, и даже необходимо.

Далее, автор советует почитать книгу Нила Стивенсона поосновам работы в конслои. Она, разумеется на английском, так что от себя добавляю несколько ссылок на русскоязычные ресурсы по теме:
http://zero.kanet.ru/site/index.php?page=15 – командная строка Linux
http://heap.altlinux.org/alt-docs/modules/unix_base_admin.dralex/ch02.html командная строка UNIX

Voilà des exemples d’utilisation de la commande ‘find’ qui me sont bien utiles quand j’établis un “état des lieux” sur une application:

Rappel: La commande find est récursive, c’est à dire où que vous tapiez, elle va aller scruter dans les répertoires et les sous répertoires de chaque répertoire et ceci de façon récursive.

- http://en.wikipedia.org/wiki/Find (“The find program is a search utility, mostly found on Unix-like platforms. It searches through one or more directory tree(s) of a filesystem, locating files based on some user-specified criteria. By default, find returns all files below the current working directory. Further, find allows the user to specify an action to be taken on each matched file. Thus, it is an extremely powerful program for applying actions to many files. It also supports regexp matching.”)

Ici cela s’applique à une application Java:

// Pour compter le nombre de lignes java
find . -name *.java -exec cat {} \; | wc -l

// Pour avoir la liste des fichiers java : ça c’est du classique
find . -name *.java -print

// Pour effacer tous les fichiers core situés sous mon répertoire :
find . -name core -exec rm {} \;

// pour avoir une demande de confirmation avant l’exécution de rm, vous pouvez taper :
find . -name core -ok rm {}\;

// Pour connaître les derniers fichiers modifiés dans les 3 derniers jours dans toute l’arborescence (/), vous devez taper :
find / -mtime 3 -print

// Pour connaître dans toute l’arborescence, les fichiers dont la taille dépasse 1Mo (2000 blocs de 512Ko), vous devez taper :
find / -size 2000 -print

// Vous pouvez chercher dans toute l’arborescence, les fichiers ordinaires appartenant à reza, dont la permission est fixée à 755, on obtient :
find / -type f -user reza -perm 755 -print

// rechercher dans le répertoire courant tous les fichiers normaux (sans les répertoires, fichiers spéciaux), et rechercher dans ces fichiers tous ceux contenant la chaîne toto.
find . -type f -print | xargs grep toto

// Exemple plus sophistiqué
find . -name *.java | xargs egrep -e “msg” | egrep -e “\”.+\”"| sort| uniq > aMsgJava.txt

// Recherche de la chaîne “DB” dans des programmes php
find . -name *.php -print | xargs grep DB

// supprimer des répertoires subversion .svn
find . -name “.svn” -exec chmod -R +w {} \;
find . -name “.svn” -exec rm -R {} \;

Liens:

• - http://www.commandlinefu.com/commands/browse (‘commandlinefu.com is the place to record those command-line gems that you return to again and again. Delete that bloated snippets file you’ve been using and share your personal repository with the world. That way others can gain from your CLI wisdom and you from theirs too. All commands can be commented on, discussed and voted up or down.’)
  • http://commandlinefu.uservoice.com/(‘If you have a new feature suggestion or find a bug, please get in touch via http://commandlinefu.uservoice.com/‘)

• - http://fr.wikipedia.org/wiki/Shell_%28informatique%29 (…”Les systèmes d’exploitation de type Unix, GNU/Linux par exemple, disposent le plus souvent d’un shell. Celui-ci est utilisable en conjonction avec un terminal (souvent virtuel). A l’origine, l’interpréteur de commandes par défaut était tcsh (et c’était le Bourne_shell sur les Unix originels), mais aujourd’hui Bash est le plus répandu. Sur les postes de travail, les shells (environnements) graphiques KDE et/ou Gnome sont les plus usités. Il existe d’autres interpréteurs de commandes, notamment zsh et rc.”)

• - http://fr.wikipedia.org/wiki/Bash (…”Bash, acronyme de Bourne-again shell, est l’interprète de commandes libre du projet GNU. Son nom est un jeu de mots (Bourne again / born again, « né de nouveau » ou encore « réincarné ») sur le shell historique d’Unix, le Bourne shell. Basé sur ce dernier, il apporte de nombreuses améliorations, provenant notamment du Korn shell et du C shell.Son auteur original est Brian Fox de la Free Software Foundation, relayé plus tard par Chet Ramey. Le Bourne shell original fut écrit par Steve Bourne.Bash est un logiciel libre publié sous licence GPL. Il est l’interprète par défaut sur de nombreux Unix libres, notamment sur les systèmes GNU/Linux. C’est aussi le shell par défaut de Mac OS X et il a été porté sous Windows par le projet Cygwin“)

• - http://fr.wikipedia.org/wiki/Commandes_Unix (Les systèmes d’exploitation de type UNIX offrent à leurs utilisateurs des centaines de commandes qui font de la console un outil très pratique et très puissant. Certaines d’entre elles sont fournies directement par le shell, alors que d’autres sont des exécutables situés dans /bin, /usr/bin, /usr/local/bin ou un autre répertoire contenant des exécutables et listé dans la variable d’environnement PATH. La distinction entre /bin et /usr/bin ne relève que de raisons historiques propres aux PDP/11 (/bin était placé sur un tambour magnétique d’accès rapide et de petite taille, /usr/bin sur un disque normal ; sur beaucoup de systèmes actuels, il s’agit d’un lien vers le même système de fichiers.)