extglob pattern: @(/root) vs. @(root)
See following: # shopt extglob extglob on # echo $BASH_VERSION 4.2.20(1)-release # ls -d /root /root # pwd / # echo @(root) root # echo @(/root) @(/root) <-- ??? # echo @(/root*) @(/root*) <-- ??? # I'm confused why @(/root) and @(/root*) do not work here. -- -Clark
Re: extglob pattern: @(/root) vs. @(root)
On Fri, Dec 9, 2011 at 16:16, Clark J. Wang wrote: > See following: > > # shopt extglob > extglob on > # echo $BASH_VERSION > 4.2.20(1)-release > # ls -d /root > /root > # pwd > / > # echo @(root) > root > # echo @(/root) > @(/root) <-- ??? > # echo @(/root*) > @(/root*) <-- ??? > But /@(root) and /@(root*) work: # echo /@(root) /root # echo /@(root*) /root # > # > > I'm confused why @(/root) and @(/root*) do not work here. > > -- > -Clark >
Re: extglob pattern: @(/root) vs. @(root)
2011-12-9, 16:16(+08), Clark J. Wang: > See following: > > # shopt extglob > extglob on > # echo $BASH_VERSION > 4.2.20(1)-release > # ls -d /root > /root > # pwd > / > # echo @(root) > root > # echo @(/root) > @(/root) <-- ??? > # echo @(/root*) > @(/root*) <-- ??? > # > > I'm confused why @(/root) and @(/root*) do not work here. Globbing operators (*, ?, [/], @(..)) don't match "/". "/" has to be inserted literally. See the doc: When a pattern is used for filename expansion, the character `.' at the start of a filename or immediately following a slash must be matched explicitly, unless the shell option `dotglob' is set. When matching a file name, the slash character must always be matched explicitly. In other cases, the `.' character is not treated specially. ~~ -- Stephane >
Re: extglob pattern: @(/root) vs. @(root)
On Fri, Dec 9, 2011 at 20:12, Stephane CHAZELAS wrote: > 2011-12-9, 16:16(+08), Clark J. Wang: > > See following: > > > > # shopt extglob > > extglob on > > # echo $BASH_VERSION > > 4.2.20(1)-release > > # ls -d /root > > /root > > # pwd > > / > > # echo @(root) > > root > > # echo @(/root) > > @(/root) <-- ??? > > # echo @(/root*) > > @(/root*) <-- ??? > > # > > > > I'm confused why @(/root) and @(/root*) do not work here. > > Globbing operators (*, ?, [/], @(..)) don't match "/". "/" has > to be inserted literally. > > See the doc: > > When a pattern is used for filename expansion, the character `.' at > the start of a filename or immediately following a slash must be > matched explicitly, unless the shell option `dotglob' is set. When > > matching a file name, the slash character must always be matched > > explicitly. In other cases, the `.' character is not treated specially. > ~~ > Thanks. I see the point now. I never really noticed that before since things like `echo /root*' always worked fine. :) > > -- > Stephane > > > > > -- -Clark
Re: super annoying completion change
On Fri, Dec 9, 2011 at 11:24, Chet Ramey wrote: > On 12/8/11 9:14 PM, Clark J. Wang wrote: > > > http://lists.gnu.org/archive/html/bug-bash/2011-09/msg7.html > > contains a basic summary and includes a patch that adds a `direxpand' > > shell option to restore the 4.1 behavior. > > > > You can download a version of bash-4.2.20 with this patch already > applied > > from the `direxpand' branch on the bash git tree on savannah. > > > > > > Bash-4.2.20 does not have `direxpand'. Did I misunderstand you? > > Yes. > I need to learn English much harder. :) > > You can either take bash-4.2.20 and manually apply the patch I posted, or, > as above, check out the `direxpand' branch from the git tree, which already > has that patch applied on top of bash-4.2.20. > > Chet > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRUc...@case.edu > http://cnswww.cns.cwru.edu/~chet/ > -- -Clark
Re: super annoying completion change
> On Fri, Dec 9, 2011 at 11:24, Chet Ramey wrote: > > > Bash-4.2.20 does not have `direxpand'. Did I misunderstand you? > > > > Yes. > > > > I need to learn English much harder. :) It can be an especially confusing language. :-) -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
lseek with bash
Playing with flock to securely access to a file shared by multiple
process. I noticed there are no documented way to do an lseek on an
opened fd with bash :
#!/bin/bash
exec 18<>/tmp/resource
flock 18
# (...) read and analyze the resource file
# ?? there is no documented way to seek or rewind in the resource...
if i redo "exec 8<>/tmp/resource" it close the file descriptor and so
unlock it for flock :-(
# write in the resource file
exec 18>&-
I have solve my problem by making this small binary (i just needed a rewind) :
int main(int argc,char * argv[]) { return lseek(atoi(argv[1]),0L,0); }
But i ll be glad to use a standard and finished tool.
Of course we could make an "lseek" binary with some options to cover
all use cases of lseek function. But I prefer to have such
functionality inside bash.
If it does not already exist, here is a proposition :
To understand some characters after a file descriptor, which imply a
lseek (if it is not a pipe or a socket) before reading or writing to
this fd :
looks like :
- $fd[sbae[0-9]*]
-or $fd[+$^-[0-9]*]
were s or ^ imply whence=SEEK_SET , and [0-9]* is the (positive)
offset in octets (default=0, s for Start or Set)
were b or - imply whence=SEEK_CUR , and [0-9]* is the (negative)
offset in octets (default=0, b for Before)
were a or + imply whence=SEEK_CUR , and [0-9]* is the (positive)
offset in octets (default=0, a for After)
were e or $ imply whence=SEEK_END , and [0-9]* is the (negative)
offset in octets (default=0, e for End)
and this is how it could be use :
read line <&18s # do an rewind before to read the (first) line
read -c 3 endchars <&18e4 # read 3 chars before the last one.
echo -n >&18b4 # just move SEEK_CUR 4 octets backward.
What do you think ?
Thx,
Jean-Jacques.
Re: lseek with bash
On Fri, Dec 09, 2011 at 04:12:15PM +0100, Jean-Jacques Brucker wrote:
> I have solve my problem by making this small binary (i just needed a rewind) :
>
> int main(int argc,char * argv[]) { return lseek(atoi(argv[1]),0L,0); }
>
> But i ll be glad to use a standard and finished tool.
That looks pretty finished to me. ;-)
> Of course we could make an "lseek" binary with some options to cover
> all use cases of lseek function. But I prefer to have such
> functionality inside bash.
This probably belongs on help-bash rather than bug-bash, although it's a
grey area. I'm Cc-ing both.
If you want this functionality inside bash, one way to achieve that would
be to write a loadable builtin, and enable it. Of course, then this would
only work on the machine where you compiled and installed that builtin.
Is this more desirable than an external "rewind" utility? Hard to say.
In terms of creating a generalized lseek solution... I honestly can't
think of a reason you would need this for shell scripts. There are
several types of problems where rewinding to 0 might be desirable
(mail delivery agents being the first to spring to mind), but seeking
to arbitrary locations sounds a bit far-fetched. If you want to read
randomly-accessed bytes from a file, you'd probably be better served
writing your program in C in the first place.
help-bash mailing list (Was: lseek with bash)
2011-12-9, 10:27(-05), Greg Wooledge: [...] > This probably belongs on help-bash rather than bug-bash, although it's a > grey area. I'm Cc-ing both. [...] First time I hear about a "help-bash" mailing list. Is that new? I saw no annoucement in bash bug (I could have missed it though), nor does it seem to be referenced on the bash homepage at gnu.org. And there doesn't seem to be a corresponding usenet newsgroup like for the other gnu.org mailing lists. And it doesn't seem it's been added to gmane (yet?). Was it announced anywhere? -- Stephane
Re: help-bash mailing list (Was: lseek with bash)
On Fri, Dec 09, 2011 at 04:32:56PM +, Stephane CHAZELAS wrote: > First time I hear about a "help-bash" mailing list. Is that new? Yes, it's new. Announced by Chet on Nov 21: http://www.mail-archive.com/bug-bash@gnu.org/msg10154.html
Russian translation for GNU Bourne-Again SHell page
Hello, we've translated to Russian your great documentation page http://tiswww.case.edu/php/chet/bash/bashtop.html Please place a link to translated article from your site: http://tiswww.case.edu/php/chet/bash/bashtop.html Text of link: http://www.portablecomponentsforall.com/edu/gnu-bourne-again-shell-be/";>Russian translation provided by http://www.portablecomponentsforall.com ">PortableComponentsForAll Best Regards, Jim
Re: lseek with bash
On 12/9/11 10:12 AM, Jean-Jacques Brucker wrote:
> Playing with flock to securely access to a file shared by multiple
> process. I noticed there are no documented way to do an lseek on an
> opened fd with bash :
[...]
> I have solve my problem by making this small binary (i just needed a rewind) :
>
> int main(int argc,char * argv[]) { return lseek(atoi(argv[1]),0L,0); }
>
> But i ll be glad to use a standard and finished tool.
>
> Of course we could make an "lseek" binary with some options to cover
> all use cases of lseek function. But I prefer to have such
> functionality inside bash.
ksh93 has this functionality with different syntax. I'm not convinced
it's of general enough value to add to bash, especially when a separate
binary (of obviously trivial complexity) does the job.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
