Re: getting weird output out of 'echo' w/args
On Thu, May 30, 2013 at 4:42 AM, Linda Walsh wrote:
>
>
> Chet Ramey wrote:
>> On 5/29/13 9:08 PM, Linda Walsh wrote:
>>> Why would I get this:
>>>
echo "gtk-2.0/2.10.0/engines/liboxygen-gtk.so
[u::rwx,u:law:rwx,g::r-x,m::rwx,o::r-x]"
>>> gtk-2.0/2.10.0/engines/liboxygen-gtk.so
>>> [u::rwx,u:law:rwx,g::r-x,m::rwx,o::r-x]
>>>
echo gtk-2.0/2.10.0/engines/liboxygen-gtk.so
[u::rwx,u:law:rwx,g::r-x,m::rwx,o::r-x]
>>> gtk-2.0/2.10.0/engines/liboxygen-gtk.so s
>>>
>>> ^^--so why doesn't it echo out it's input arguments? Where did the acl go?
>>> into 's'? ;-/
>>
>> Are you familiar with filename generation, commonly known as `globbing'?
>>
>
>
> Are you saying it took bracketed thing as a gorup of chars to match?
> oh... and the r-x was a range that picked up a singled file 's'... ARG!...
> oi oi oi...
>
> Thanks -- I was hoping it has some simple explanation that I just wasn't
> seeing.
> (I was only thinking of escape sequences...)...
>
> Cheers!
> Linda
>
Missing quotes around [ ] can be nasty eg
#!/bin/bash
shopt -s nullglob # sounds a good idea!
.
.
i=0
while read a[i++]; do
echo "${a[i]}" # why oh why nothing is printed!
done <<< "hello"
Re: getting weird output out of 'echo' w/args
Chet Ramey wrote: > On 5/29/13 9:08 PM, Linda Walsh wrote: >> Why would I get this: >> >>> echo "gtk-2.0/2.10.0/engines/liboxygen-gtk.so >>> [u::rwx,u:law:rwx,g::r-x,m::rwx,o::r-x]" >> gtk-2.0/2.10.0/engines/liboxygen-gtk.so >> [u::rwx,u:law:rwx,g::r-x,m::rwx,o::r-x] >> >>> echo gtk-2.0/2.10.0/engines/liboxygen-gtk.so >>> [u::rwx,u:law:rwx,g::r-x,m::rwx,o::r-x] >> gtk-2.0/2.10.0/engines/liboxygen-gtk.so s >> >> ^^--so why doesn't it echo out it's input arguments? Where did the acl go? >> into 's'? ;-/ > > Are you familiar with filename generation, commonly known as `globbing'? > Are you saying it took bracketed thing as a gorup of chars to match? oh... and the r-x was a range that picked up a singled file 's'... ARG!... oi oi oi... Thanks -- I was hoping it has some simple explanation that I just wasn't seeing. (I was only thinking of escape sequences...)... Cheers! Linda
Re: getting weird output out of 'echo' w/args
On 5/29/13 9:08 PM, Linda Walsh wrote: > Why would I get this: > >> echo "gtk-2.0/2.10.0/engines/liboxygen-gtk.so >> [u::rwx,u:law:rwx,g::r-x,m::rwx,o::r-x]" > gtk-2.0/2.10.0/engines/liboxygen-gtk.so > [u::rwx,u:law:rwx,g::r-x,m::rwx,o::r-x] > >> echo gtk-2.0/2.10.0/engines/liboxygen-gtk.so >> [u::rwx,u:law:rwx,g::r-x,m::rwx,o::r-x] > gtk-2.0/2.10.0/engines/liboxygen-gtk.so s > > ^^--so why doesn't it echo out it's input arguments? Where did the acl go? > into 's'? ;-/ Are you familiar with filename generation, commonly known as `globbing'? -- ``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/
getting weird output out of 'echo' w/args
Why would I get this: > echo "gtk-2.0/2.10.0/engines/liboxygen-gtk.so > [u::rwx,u:law:rwx,g::r-x,m::rwx,o::r-x]" gtk-2.0/2.10.0/engines/liboxygen-gtk.so [u::rwx,u:law:rwx,g::r-x,m::rwx,o::r-x] > echo gtk-2.0/2.10.0/engines/liboxygen-gtk.so > [u::rwx,u:law:rwx,g::r-x,m::rwx,o::r-x] gtk-2.0/2.10.0/engines/liboxygen-gtk.so s ^^--so why doesn't it echo out it's input arguments? Where did the acl go? into 's'? ;-/ bash ver=4.2.45(1)-release options (shopt): +autocd +cdable_vars +cdspell +checkhash -checkjobs +checkwinsize +cmdhist -compat31 -compat32 -compat40 -compat41 -direxpand +dirspell +dotglob -execfail +expand_aliases -extdebug +extglob +extquote -failglob +force_fignore +globstar -gnu_errfmt +histappend +histreedit +histverify +hostcomplete -huponexit +interactive_comments -lastpipe +lithist +login_shell -mailwarn +no_empty_cmd_completion +nocaseglob +nocasematch -nullglob +progcomp +promptvars -restricted_shell -shift_verbose +sourcepath +xpg_echo (set): -allexport +braceexpand -emacs -errexit -errtrace -functrace +hashall -histexpand +history -ignoreeof +interactive-comments -keyword +monitor -noclobber -noexec -noglob -nolog -notify -nounset -onecmd -physical +pipefail -posi-privileged -verbose +vi -xtrace Is this something peculiar to my distro again, or hopefully something with simpler explanation? Maybe the [] have some meta meaning now on output? Weird...
Re: Obsolete SIGRTMAX-n signal names
On 05/29/2013 09:04 AM, John Reiser wrote: > Comment: In practice SIGRTMIN is a very stable value. For each architecture > SIGRTMIN is chosen at the time of the original port, and after that SIGRTMIN > "never" will change, although in theory it could. The value of SIGRTMAX > is less stable because it changes whenever _NSIG changes. _NSIG has changed > from 32 to 64, and in some cases has reverted to 32 in order to save 4 bytes > [or 4*sizeof(void *)] in various places, and to make code smaller and simpler > [because (32/8)==sizeof(unsigned int)]. _NSIG == 32 is only possible on platforms that are not aiming for POSIX compliance; POSIX requires enough signals, including a minimum of 8 realtime signals, that you pretty much need _NSIG == 64 to comply with POSIX. That said, cygwin is a platform that has not (yet) converted to _NSIG == 64, and currently cheats by providing SIGRTMIN == SIGRTMAX for only 1 realtime signal. I agree that SIGRTMIN is unlikely to change for a given platform, except in the rare case of an API change from 32 to 64 (requiring a recompile of pretty much everything on that platform to take advantage of the new API, while still providing ABI compatibility for older applications to continue to run even without recompilation). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Obsolete SIGRTMAX-n signal names
On 05/29/2013 01:35 AM, Harald Hoyer wrote: > On 04/24/2013 05:26 PM, Chet Ramey wrote: >> On 4/23/13 2:05 AM, Harald Hoyer wrote: >>> As reported in http://savannah.gnu.org/patch/?8025 , I would like to see the >>> SIGRTMAX-n signal names disappear. >>> >>> Signals should never ever be addressed with SIGRTMAX-n. Signals should >>> always be >>> addressed with SIGRTMIN+n. >> >> I'll take a look at this, but that's a pretty strong statement to make from >> something that appears in one Linux man page. I can't find any shell in my >> quick testing that behaves as you propose. Is there any other reason to do >> this? >> >> Chet >> >> > > Any progress, comments? Comment: In practice SIGRTMIN is a very stable value. For each architecture SIGRTMIN is chosen at the time of the original port, and after that SIGRTMIN "never" will change, although in theory it could. The value of SIGRTMAX is less stable because it changes whenever _NSIG changes. _NSIG has changed from 32 to 64, and in some cases has reverted to 32 in order to save 4 bytes [or 4*sizeof(void *)] in various places, and to make code smaller and simpler [because (32/8)==sizeof(unsigned int)]. --
Re: Obsolete SIGRTMAX-n signal names
On 04/24/2013 05:26 PM, Chet Ramey wrote: > On 4/23/13 2:05 AM, Harald Hoyer wrote: >> As reported in http://savannah.gnu.org/patch/?8025 , I would like to see the >> SIGRTMAX-n signal names disappear. >> >> Signals should never ever be addressed with SIGRTMAX-n. Signals should >> always be >> addressed with SIGRTMIN+n. > > I'll take a look at this, but that's a pretty strong statement to make from > something that appears in one Linux man page. I can't find any shell in my > quick testing that behaves as you propose. Is there any other reason to do > this? > > Chet > > Any progress, comments?
