Re: [PATCH] safelocale
Greg Wooledge wrote: > I wrote this after learning of a security hole in $"..." expansion. > (See http://www.gnu.org/software/gettext/manual/html_node/bash.html > for details of that.) It seems to me that the security hole is the possibility of command substitution, rather than arbitary word expansions, which are inconvenient at worst. Inhibiting all expansions to protect against possibly malicious translated strings is a rather large stick to use. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Possibly Off Topic Rant
Hello, I'm a fairly new user in Linux, and I've been studying and attempting to use the commands available to me at the command line by reading the man and info pages. I'm running into lots of problems determining the proper syntax for many of the commands due to very sketchy documentation. I'm winding up trying some commands over and over again, as I attempt to discover the apparently secret twists to the syntax required to get a command to do it's thing. After many tries I sometimes finally get it right, and there is no mention in the docs of the requirement for the use of specific syntax options I eventually discover are required to use a command. I consider this a bug in the documentation, and think it would be nice if the documentation writers would add a --verbose --verbose switch to their writing behaviors when producing man pages. Later, Ray Parrish -- Human reviewed index of links about the computer http://www.rayslinks.com Poetry from the mind of a Schizophrenic http://www.writingsoftheschizophrenic.com/
Re: Possibly Off Topic Rant
Ray Parrish wrote: > Hello, > > I'm a fairly new user in Linux, and I've been studying and attempting to > use the commands available to me at the command line by reading the man > and info pages. I'm running into lots of problems determining the proper > syntax for many of the commands due to very sketchy documentation. > > I'm winding up trying some commands over and over again, as I attempt to > discover the apparently secret twists to the syntax required to get a > command to do it's thing. After many tries I sometimes finally get it > right, and there is no mention in the docs of the requirement for the > use of specific syntax options I eventually discover are required to use > a command. > > I consider this a bug in the documentation, and think it would be nice > if the documentation writers would add a --verbose --verbose switch to > their writing behaviors when producing man pages. There are literally hundreds of books available on Unix use, programming, and shell scripting. They fill this niche, not manual pages. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Possibly Off Topic Rant
Chet Ramey wrote: Ray Parrish wrote: Hello, I'm a fairly new user in Linux, and I've been studying and attempting to use the commands available to me at the command line by reading the man and info pages. I'm running into lots of problems determining the proper syntax for many of the commands due to very sketchy documentation. I'm winding up trying some commands over and over again, as I attempt to discover the apparently secret twists to the syntax required to get a command to do it's thing. After many tries I sometimes finally get it right, and there is no mention in the docs of the requirement for the use of specific syntax options I eventually discover are required to use a command. I consider this a bug in the documentation, and think it would be nice if the documentation writers would add a --verbose --verbose switch to their writing behaviors when producing man pages. There are literally hundreds of books available on Unix use, programming, and shell scripting. They fill this niche, not manual pages. Chet Granted, and I've installed quite a few of them from the repositories, but it would be nice if the man pages would at least mention things like "this parameter has to be quoted to work" or use a * on the end of the path to activate the --recursive option. It took me hours to find that out with the ls command, see following output. - r...@ray-desktop:~$ ls --recursive -d /proc/ /proc/ r...@ray-desktop:~$ ls --recursive -d /proc/* /proc/1 /proc/4 /proc/8973 /proc/9826 /proc/fs /proc/10012 /proc/41 /proc/8976 /proc/9828 /proc/interrupts /proc/10018 /proc/44 /proc/8979 /proc/9829 /proc/iomem /proc/10023 /proc/45 /proc/9041 /proc/9833 /proc/ioports /proc/10025 /proc/4521 /proc/9059 /proc/9860 /proc/irq /proc/10027 /proc/5 /proc/9060 /proc/9889 /proc/kallsyms /proc/10029 /proc/5867 /proc/9083 /proc/9891 /proc/kcore /proc/10050 /proc/6 /proc/9084 /proc/9897 /proc/key-users /proc/10058 /proc/6101 /proc/9093 /proc/9902 /proc/kmsg /proc/10060 /proc/6149 /proc/9105 /proc/9911 /proc/loadavg /proc/10063 /proc/6190 /proc/9109 /proc/9916 /proc/locks /proc/10066 /proc/6239 /proc/9203 /proc/9917 /proc/meminfo /proc/10069 /proc/6254 /proc/9209 /proc/9921 /proc/misc /proc/10077 /proc/7 /proc/9211 /proc/9922 /proc/modules /proc/10083 /proc/7032 /proc/9213 /proc/9923 /proc/mounts /proc/10106 /proc/7033 /proc/9224 /proc/9929 /proc/mtrr /proc/10110 /proc/7037 /proc/9261 /proc/9957 /proc/net /proc/10122 /proc/7038 /proc/9269 /proc/9960 /proc/pagetypeinfo /proc/10126 /proc/7040 /proc/9272 /proc/9966 /proc/partitions /proc/10159 /proc/7151 /proc/9273 /proc/9969 /proc/sched_debug /proc/10207 /proc/7191 /proc/9282 /proc/9972 /proc/scsi /proc/164 /proc/7270 /proc/9290 /proc/9975 /proc/self /proc/1826 /proc/7338 /proc/9297 /proc/9978 /proc/slabinfo /proc/1829 /proc/7340 /proc/9339 /proc/9995 /proc/stat /proc/1843 /proc/7374 /proc/9342 /proc/acpi /proc/swaps /proc/1849 /proc/7402 /proc/9346 /proc/asound /proc/sys /proc/2 /proc/7416 /proc/9502 /proc/buddyinfo /proc/sysrq-trigger /proc/203 /proc/7429 /proc/9530 /proc/bus /proc/sysvipc /proc/204 /proc/7449 /proc/9680 /proc/cgroups /proc/timer_list /proc/2408 /proc/7450 /proc/9684 /proc/cmdline /proc/timer_stats /proc/2412 /proc/7479 /proc/9719 /proc/cpuinfo /proc/tty /proc/245 /proc/7754 /proc/9776 /proc/crypto /proc/uptime /proc/2679 /proc/7874 /proc/9790 /proc/devices /proc/version /proc/2681 /proc/7911 /proc/9797 /proc/diskstats /proc/version_signature /proc/2926 /proc/8646 /proc/9800 /proc/dma /proc/vmcore /proc/2929 /proc/8934 /proc/9803 /proc/driver /proc/vmstat /proc/3 /proc/8935 /proc/9804 /proc/execdomains /proc/zoneinfo /proc/3046 /proc/8945 /proc/9808 /proc/fb /proc/3760 /proc/8970 /proc/9815 /proc/filesystems r...@ray-desktop:~$ And as another note, even 'though I've used the -d switch to show only directories in the output I'm still getting filenames with it. I also expected the command to keep recursing into the subdirectories of /proc/ and list the directories there, but no such luck. What gives? Here's what the man page says - -d, --directory list directory entries instead of contents, and do not dereference symbolic links -R, --recursive list subdirectories recursively I still don't know how to get it to dig deeper and give me all of the subdirectories, or how to get it to actually output only directory names. And you wouldn't believe the amount of time it took me to formulate the following command to get what I wanted. find -maxdepth 1 -printf '%f %T+\n' | sort -s -t ' ' -k 2.1nr -k 2.6n -k 2.9n -k 2.12r -k 2.15 -k 2.18 From the find man page below you will note that it doesn't mention the fact that the printf parameters need to be quoted to work. -printf format True; print format on the standard output, interpreting ‘\’ escapes and ‘%’ directives. Field widths and precisions can be specified as with the ‘printf’ C function. Please note that many of the fields are printed as %s rather than %d, and this may mean that flags don’t work
2 regressions related to PROMPT_COMMAND
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/a/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 uname output: Linux ul 2.6.27-12-generic #1 SMP Thu Feb 5 09:26:42 UTC 2009 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.0 Patch Level: 0 Release Status: release Description: Neither of these happen on the same system with 3.2.39(1)-release. Bug #1: do: PROMPT_COMMAND='$(cd)' Then do anything that would change your prompt, for example change directories when PS1 contains the current directory. You will see the prompt will never update when PROMPT_COMMAND contains any command substitution. It just remains whatever it was when this was set. I used $(cd) as a trivial command substitution, but any command substitution seems to have the same effect. I actually had some useful code including parameter expansions going on in my PROMPT_COMMAND. This took quite a while to figure out. Bug #2: do: PS1= PROMPT_COMMAND='echo -ne $PWD' press up, then down. This brings up the last history and then goes to the new command again. The cursor goes goes to the beginning of the line screwing up text from PROMPT_COMMAND. This also happens with vi-mode commands. I put PS1= so that it doesn't confuse the issue, but that is not necessary. Btw, thanks for bash 4. :) - Ian Kelling
Re: Possibly Off Topic Rant
On Monday 02 March 2009 00:22:15 Ray Parrish wrote: > but it would be nice if the man pages would at least mention things like > "this parameter has to be quoted to work" or use a * on the end of the > path to activate the --recursive option. It took me hours to find that > out with the ls command, see following output. the shell expanding * has nothing to do with any specific command. like Chet said, that's a basic premise of using a *nix system that any half decent book out there would cover. > And as another note, even 'though I've used the -d switch to show only > directories in the output I'm still getting filenames with it. I also > expected the command to keep recursing into the subdirectories of /proc/ > and list the directories there, but no such luck. What gives? Here's > what the man page says - this is the "bash" list, not coreutils (which owns the "ls" program). if you want clearer info there, talk to them. > And you wouldn't believe the amount of time it took me to formulate the > following command to get what I wanted. > > find -maxdepth 1 -printf '%f %T+\n' | sort -s -t ' ' -k 2.1nr -k 2.6n -k > 2.9n -k 2.12r -k 2.15 -k 2.18 > > From the find man page below you will note that it doesn't mention the > fact that the printf parameters need to be quoted to work. yet another basic issue not specific to any command. reading a book would address this. > And here is the skimpy info in the sort man page for the -k parameter. - sort is from coreutils, not bash. -mike signature.asc Description: This is a digitally signed message part.
