Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.misc > #7091 > unrolled thread
| Started by | Jon Danniken <jonSPAMdanniken@yaSMPAhoo.com> |
|---|---|
| First post | 2013-01-25 08:59 -0800 |
| Last post | 2013-01-25 20:11 -0500 |
| Articles | 3 on this page of 23 — 10 participants |
Back to article view | Back to comp.os.linux.misc
Case insensitive bash search? Jon Danniken <jonSPAMdanniken@yaSMPAhoo.com> - 2013-01-25 08:59 -0800
Re: Case insensitive bash search? Robert Heller <heller@deepsoft.com> - 2013-01-25 11:44 -0600
Re: Case insensitive bash search? gazelle@shell.xmission.com (Kenny McCormack) - 2013-01-29 13:56 +0000
Re: Case insensitive bash search? Wayne <nospam@all.invalid> - 2013-01-29 12:41 -0500
Re: Case insensitive bash search? unruh <unruh@invalid.ca> - 2013-01-25 17:59 +0000
Re: Case insensitive bash search? Lew Pitcher <lpitcher@teksavvy.com> - 2013-01-25 13:13 -0500
Re: Case insensitive bash search? Lew Pitcher <lpitcher@teksavvy.com> - 2013-01-25 13:23 -0500
Re: Case insensitive bash search? Richard Kettlewell <rjk@greenend.org.uk> - 2013-01-25 19:48 +0000
Re: Case insensitive bash search? ray carter <ray@zianet.com> - 2013-01-25 20:45 +0000
Re: Case insensitive bash search? Jon Danniken <jonSPAMdanniken@yaSMPAhoo.com> - 2013-01-25 14:58 -0800
Re: Case insensitive bash search? Jon Danniken <jonSPAMdanniken@yaSMPAhoo.com> - 2013-01-25 15:28 -0800
Re: Case insensitive bash search? Jon Danniken <jonSPAMdanniken@yaSMPAhoo.com> - 2013-01-25 16:14 -0800
Re: Case insensitive bash search? Robert Heller <heller@deepsoft.com> - 2013-01-25 19:04 -0600
Re: Case insensitive bash search? unruh <unruh@invalid.ca> - 2013-01-26 06:51 +0000
Re: Case insensitive bash search? unruh <unruh@invalid.ca> - 2013-01-26 06:47 +0000
Re: Case insensitive bash search? unruh <unruh@invalid.ca> - 2013-01-26 16:36 +0000
Re: Case insensitive bash search? Tim Watts <tw+usenet@dionic.net> - 2013-01-25 20:01 +0000
Re: Case insensitive bash search? Jon Danniken <jonSPAMdanniken@yaSMPAhoo.com> - 2013-01-25 15:01 -0800
Re: Case insensitive bash search? Tim Watts <tw+usenet@dionic.net> - 2013-01-25 23:36 +0000
Re: Case insensitive bash search? Jon Danniken <jonSPAMdanniken@yaSMPAhoo.com> - 2013-01-25 16:09 -0800
Re: Case insensitive bash search? Tim Watts <tw+usenet@dionic.net> - 2013-01-26 11:21 +0000
Re: Case insensitive bash search? Jon Danniken <jonSPAMdanniken@yaSMPAhoo.com> - 2013-01-26 15:14 -0800
Re: Case insensitive bash search? "Chris F.A. Johnson" <cfajohnson@gmail.com> - 2013-01-25 20:11 -0500
Page 2 of 2 — ← Prev page 1 [2]
| From | Tim Watts <tw+usenet@dionic.net> |
|---|---|
| Date | 2013-01-26 11:21 +0000 |
| Message-ID | <6qqct9-55l.ln1@squidward.local.dionic.net> |
| In reply to | #7103 |
On Saturday 26 January 2013 00:09 Jon Danniken wrote in comp.os.linux.misc: > On 01/25/2013 03:36 PM, Tim Watts wrote: >> On Friday 25 January 2013 23:01 Jon Danniken wrote in comp.os.linux.misc: >> >>> Thanks Tim. My reason for trying to do this in the shell (as opposed to >>> in a file manager) is because I have some folders with a lot of files in >>> them (thousands to tens of thousands), and my file manager (Dolphin - >>> KDE) often has problems at times with folders that big. >>> >>> I find that using the shell is a *lot* quicker than the file manager, >>> and very noticeably so when interacting with one of these >>> "high-capacity" folders. >> >> I really meant "are you obsessed with not exec-ing other command >> binaries"? That could be a valid concern on a crappy little embedded >> system, but not usually a problem on a normal system - unless you are >> trying to aim for 100% portability across loads of unices - where you >> cannot assume GNU extensions etc. > > Okay, I gotcha. I'm not at that level (yet), just a home PC user for > the time being. > > Jon In that case, "find" and/or "ls -1" plus "grep" and the putput piped through "xargs" (which runs a command with all the input lines as arguments - or can run the command once per input line) can do an awful lot. I always put "echo" after "xargs" the first time just to make sure the commands look right, before running them. eg copy all files in /etc/ (non recursively) that have the second letter "A" case-insensitive to /tmp/etc mkdir /tmp/etc find /etc/ -maxdepth 1 -iname \?A\* | xargs \ --replace=FILE echo cp -v FILE /tmp/etc/ and to actually do it, remove the echo: find /etc/ -maxdepth 1 -iname \?A\* | xargs \ --replace=FILE cp -v FILE /tmp/etc/ (The multiple lines are only for the benefit of the newsreader wrapping) The above will find directories too and cp will ignore them. As an excercise, how could you modify the command to skip directories? -- Tim Watts Personal Blog: http://www.dionic.net/tim/ "History will be kind to me for I intend to write it."
[toc] | [prev] | [next] | [standalone]
| From | Jon Danniken <jonSPAMdanniken@yaSMPAhoo.com> |
|---|---|
| Date | 2013-01-26 15:14 -0800 |
| Message-ID | <ke1o0r$2m9$1@speranza.aioe.org> |
| In reply to | #7109 |
On 01/26/2013 03:21 AM, Tim Watts wrote: > On Saturday 26 January 2013 00:09 Jon Danniken wrote in comp.os.linux.misc: > >> On 01/25/2013 03:36 PM, Tim Watts wrote: >>> On Friday 25 January 2013 23:01 Jon Danniken wrote in comp.os.linux.misc: >>> >>>> Thanks Tim. My reason for trying to do this in the shell (as opposed to >>>> in a file manager) is because I have some folders with a lot of files in >>>> them (thousands to tens of thousands), and my file manager (Dolphin - >>>> KDE) often has problems at times with folders that big. >>>> >>>> I find that using the shell is a *lot* quicker than the file manager, >>>> and very noticeably so when interacting with one of these >>>> "high-capacity" folders. >>> >>> I really meant "are you obsessed with not exec-ing other command >>> binaries"? That could be a valid concern on a crappy little embedded >>> system, but not usually a problem on a normal system - unless you are >>> trying to aim for 100% portability across loads of unices - where you >>> cannot assume GNU extensions etc. >> >> Okay, I gotcha. I'm not at that level (yet), just a home PC user for >> the time being. >> >> Jon > > In that case, "find" and/or "ls -1" plus "grep" and the putput piped through > "xargs" (which runs a command with all the input lines as arguments - or can > run the command once per input line) can do an awful lot. > > I always put "echo" after "xargs" the first time just to make sure the > commands look right, before running them. > > eg > > copy all files in /etc/ (non recursively) that have the second letter "A" > case-insensitive to /tmp/etc > > > mkdir /tmp/etc > find /etc/ -maxdepth 1 -iname \?A\* | xargs \ > --replace=FILE echo cp -v FILE /tmp/etc/ > > and to actually do it, remove the echo: > > find /etc/ -maxdepth 1 -iname \?A\* | xargs \ > --replace=FILE cp -v FILE /tmp/etc/ > > > (The multiple lines are only for the benefit of the newsreader wrapping) > > The above will find directories too and cp will ignore them. As an > excercise, how could you modify the command to skip directories? Thanks, Tim. There will a time when I will be able to understand how that works, but that will be awhile from now. I have copied it, however, and as my understanding of bash and scripting improves, revisit it until it makes sense to me. For now, I am limited to my baby steps. :) Jon
[toc] | [prev] | [next] | [standalone]
| From | "Chris F.A. Johnson" <cfajohnson@gmail.com> |
|---|---|
| Date | 2013-01-25 20:11 -0500 |
| Message-ID | <s3nbt9-ob2.ln1@cfa.johnson> |
| In reply to | #7102 |
On 2013-01-25, Tim Watts wrote: > On Friday 25 January 2013 23:01 Jon Danniken wrote in comp.os.linux.misc: > >> On 01/25/2013 12:01 PM, Tim Watts wrote: >>> On Friday 25 January 2013 16:59 Jon Danniken wrote in comp.os.linux.misc: >>> >>>> Hello, >>>> >>>> Is it possible to have the search of a folder with "ll" return all >>>> case-insensitive results? >>>> >>>> As an example, if I search for "*Foo*", I will only get files that have >>>> the capital "F", but not "foo". >>>> >>>> Is there any way to have results returned regardless of case? >>>> >>>> Thanks, >>>> >>>> Jon >>> >>> find -iname ... -maxdepth 1 >>> >>> Or do you *really* want to do it in the shell? >> >> Thanks Tim. My reason for trying to do this in the shell (as opposed to >> in a file manager) is because I have some folders with a lot of files in >> them (thousands to tens of thousands), and my file manager (Dolphin - >> KDE) often has problems at times with folders that big. >> >> I find that using the shell is a *lot* quicker than the file manager, >> and very noticeably so when interacting with one of these >> "high-capacity" folders. > > I really meant "are you obsessed with not exec-ing other command binaries"? > That could be a valid concern on a crappy little embedded system, but not > usually a problem on a normal system It can be important on any system. If all the processing can be done by a single call to an external command, that's fine, but if it has to be called in a loop, it can make a vast difference to the time it takes. Since snippets of code are often incorporated into larger scripts, inefficiences arfe magnified. -- Chris F.A. Johnson, <http://cfajohnson.com> Author: Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress) Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | comp.os.linux.misc
csiph-web