Here is the smoking gun

[Pete]

The memo that has "IMPEACH HIM" written all over it.

The top-level government memo marked "SECRET AND STRICTLY PERSONAL",
dated eight months before Bush sent us into Iraq, following a closed 
meeting with the President, reads, "Military action was now seen as 
inevitable. Bush wanted to remove Saddam through military action 
justified by the conjunction of terrorism and WMD. But the intelligence 
and facts were being fixed around the policy."

Read that again: "The intelligence and facts were being fixed"

For years, after each damning report on BBC TV, viewers inevitably ask me, 
"Isn't this grounds for impeachment?" -- vote rigging, a blind eye to 
terror and the bin Ladens before 9-11, and so on.  Evil, stupidity and 
self-dealing are shameful but not impeachable.  What's needed is a "high 
crime or misdemeanor." 

And if this ain't it, nothing is.

The memo uncovered this week by the TIMES, goes on to describe an elaborate 
plan by George Bush and British Prime Minister Tony Blair to hoodwink the 
lanet into supporting an attack on Iraq knowing full well the evidence for 
war was a phony.

A conspiracy to commit serial fraud is, under federal law, racketeering. 
However, the Mob's schemes never cost so many lives.  Here's more. "Bush had 
made up his mind to take military action. But the case was thin. Saddam was 
not threatening his neighbors, and his WMD capability was less than that of 
Libya, North Korea or Iran." 

Really? But Mr. Bush told us, "Intelligence gathered by this and other 
governments leaves no doubt that the Iraq regime continues to possess and 
conceal some of the most lethal weapons ever devised."

A month ago, the Silberman-Robb Commission issued its report on WMD 
intelligence before the war, dismissing claims that Bush fixed the facts
with this snooty, condescending conclusion written directly to the
President, "After a thorough review, the Commission found no indication
that the Intelligence Community distorted the evidence regarding Iraq's
weapons." We now know the report was a bogus 618 pages of thick
whitewash aimed to let Bush off the hook for his murderous mendacity.
Read on: The invasion build-up was then set, says the memo, "beginning
30 days before the US Congressional elections." Mission accomplished.
You should parse the entire memo -- reprinted below -- and see if you
can make it through its three pages without losing your lunch. Now sharp
readers may note they didn't see this memo, in fact, printed in the New York
Times. It wasn't. Rather, it was splashed across the front pages of the 
Times of LONDON on Monday. 

It has effectively finished the last, sorry remnants of Tony Blair's
political career. (While his Labor Party will most assuredly win the
elections Thursday, Prime Minister Blair is expected, possibly within
months, to be shoved overboard in favor of his Chancellor of the
Exchequer, a political execution which requires only a vote of the
Labour party's members in Parliament.)

But in the US, barely a word. The New York Times covers this hard
evidence of Bush's fabrication of a casus belli as some "British"
elections story. Apparently, our President's fraud isn't "news fit to
print."

My colleagues in the UK press have skewered Blair, digging out more
incriminating memos, challenging the official government factoids and
fibs. But in the US press nada, bubkes, zilch. Bush fixed the facts and
somehow that's a story for "over there."

The Republicans impeached Bill Clinton over his cigar and Monica's
affections. And the US media could print nothing else. Now, we have the
stone, cold evidence of bending intelligence to sell us on death by the
thousands, and neither a Republican Congress nor what is laughably
called US journalism thought it worth a second look.

My friend Daniel Ellsberg once said that what's good about the American
people is that you have to lie to them. What's bad about Americans is
that it's so easy to do.

Greg Palast, former columnist for Britain's
Guardian papers, is the author of the New York Times bestseller, "The
Best Democracy Money Can Buy".  Subscribe to his columns at GregPalast.COM.
Media requests to CONTACT(at)GregPalast.COM.
Permission to reprint with attribution granted.

[Here it is - the secret smoking gun memo
 - discovered by the Times of London. - GP]

SECRET AND STRICTLY PERSONAL - UK EYES ONLY
DAVID MANNING 

From: Matthew Rycroft

Date: 23 July 2002 S 195 /02

cc: Defence Secretary,Foreign Secretary, Attorney-General, 
Sir Richard Wilson, John Scarlett, Francis Richards, CDS, C, 
Jonathan Powell, Sally Morgan, Alastair Campbell

IRAQ: PRIME MINISTER'S MEETING, 23 JULY

Copy addressees and you met the Prime Minister on 23 July to discuss Iraq.

This record is extremely sensitive. No further copies should be made. It
should be shown only to those with a genuine need to know its contents.

John Scarlett summarised the intelligence and latest JIC assessment.
Saddam's regime was tough and based on extreme fear. T

exec vs. source spawning piped commands

[Pete Nelson]

$ bash --version
GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ uname -a
Linux host02 2.6.32-30-server #59-Ubuntu SMP Tue Mar 1 22:46:09 UTC 2011
x86_64 GNU/Linux


I'm confused about what exec is doing in this case.

Sample script t:

#!/bin/bash
echo $0 pid: $$ ppid: $PPID args: $* 1>&2
if [ -z "$1" ]; then
  exec $0 first | $0 second
  echo should not reach here
fi

output:

$ ./t
./t pid: 13746 ppid: 12823 args:
/home/user/t pid: 13747 ppid: 13746 args: first
./t pid: 13748 ppid: 13746 args: second
should not reach here

Using exec, I would expect the second line (arg: first) to have the same pid
and ppid, but it forks a new process.  All it appears exec does in this case
is expand the relative path to a full path.  Running it without exec returns
the same pattern of pid and ppid values:

$ ./t
./t pid: 13766 ppid: 12823 args:
./t pid: 13767 ppid: 13766 args: first
./t pid: 13768 ppid: 13766 args: second
should not reach here


Using source instead of exec does run the first piped command in the current
shell process, as expected.  In that case, I would have to replace the last
echo line with an exit to meet my intentions:

#!/bin/bash
echo $0 pid: $$ ppid: $PPID args: $* 1>&2
if [ -z "$1" ]; then
  source $0 first | $0 second
  exit
fi

returns:

$ ./t
./t pid: 13792 ppid: 12823 args:
./t pid: 13792 ppid: 12823 args: first
./t pid: 13794 ppid: 13792 args: second


My intention is to give the second piped process the ability to send signals
to the first using its $PPID variable.

Re: Web urls cannot be accessed from Bash Terminal

[Pete Graner]

On 9/17/07, Pratiksha Powar <[EMAIL PROTECTED]> wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: i686
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' 
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-redhat-linux-gnu' 
> -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' 
> -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib  -D_GNU_SOURCE 
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall 
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
> --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic 
> -fasynchronous-unwind-tables
> uname output: Linux localhost.localdomain 2.6.18-8.el5 #1 SMP Thu Mar 15 
> 19:57:35 EDT 2007 i686 i686 i386 GNU/Linux
> Machine Type: i686-redhat-linux-gnu
>
> Bash Version: 3.1
> Patch Level: 17
> Release Status: release
> Yum Version : 3.0.5
>
> Description:
>   Yum not able to access url through bash
>
> Repeat-By:
>   Following is the sequence of commands and the results:
>
>  1. [EMAIL PROTECTED] /]# yum install gcc
>  2. Loading "installonlyn" plugin
>  3. Setting up Install Process
>  4. Setting up repositories
>  5. Could not retrieve mirrorlist
> http://apt.sw.be/redhat/el5/en/mirrors-rpmforge error was
>  6. [Errno 4] IOError: 
>  7. Error: Cannot find a valid baseurl for repo: rpmforge
>
> I don't know whether it is a problem with Bash or yum.
> I suppose it is bash only. Also, if I need to upgrade to the
> latest version of Bash where would I get a reliable binary
> for the above stated architecture.
>
>
>
> Thanks,
> Pratiksha
>
>
>
>

This is a not even a yum problem, its a network/upstream server
problem. If you cut an paste the URL into your browser you will get
the information.

~p
-- 
Pete Graner <[EMAIL PROTECTED]>
Manager - Base Operating Systems
Red Hat Inc.

ulimit block size

[Pete Graner]

We received a bug report[1] against bash-3.2 in Fedora 7, where the
reporter states that ulimit in bash is using a block size of 1024 vs.
512 which is in the opengroup standard[2].

What the upstream position on this?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=314461
[2] http://www.opengroup.org/onlinepubs/95399/utilities/ulimit.html
http://www.opengroup.org/onlinepubs/009695399/functions/ulimit.html

Thanks

~p
-- 
Pete Graner <[EMAIL PROTECTED]>
Base Operating Systems
Red Hat Inc.

Re: ulimit block size

[Pete Graner]

On 10/1/07, Chet Ramey <[EMAIL PROTECTED]> wrote:
> > We received a bug report[1] against bash-3.2 in Fedora 7, where the
> > reporter states that ulimit in bash is using a block size of 1024 vs.
> > 512 which is in the opengroup standard[2].
> >
> > What the upstream position on this?
>
> I'll take a look.  If bash is using 1024 while in posix mode, it's a bug.
>

Looking I don't see where is could be changed based on POSIX, according to:

bash-3.2/builtins/ulimit.def:

static RESOURCE_LIMITS limits[] = {
#ifdef RLIMIT_CORE
  { 'c',RLIMIT_CORE,  1024, "core file size",  "blocks" },
#endif

~p
-- 
Pete Graner <[EMAIL PROTECTED]>
Base Operating Systems
Red Hat Inc.

Bash bug with ints beyond 2147483646

[Pete Gregory]

Even with a 64-bit kernel, under bash4.1-2 under ubuntu 10.04, problems exist 
with numbers beyond 2147483646.

Easy duplication method:
echo {2147483640..2147483646}
reports 
2147483640 2147483641 2147483642 2147483643 2147483644 2147483645 2147483646
echo {2147483640..2147483647}
dies with a malloc error


larger numbers are accepted but cause similar issues - perhaps because it is 
internally treating these as signed 32-bit ints?

It would be great if things could 'just work'

Regards
Pete

Issus with popd and pushd

[Pete Smith]

The problem with: dirs, pushd, popd is that they output a single line of
paths that's difficult to parse visually quickly, especially when there are
many paths in the dir stack and the path
names are long.

dirs offers a reasonable solution with the -v option

Unfortunately popd and pushd do NOT offer this option.

Using an alias solution:

  popd | sed 's/\s/\n/g' | nl

doesn't work, probably because they are shell built-ins.

I'd recommend the addition of the -v option to popd and pushd, or a fix so
that an alias like the one outline above, works.

Appreciate your comments and feedback on this.

-Pete

Re: Issus with popd and pushd

[Pete Smith]

Ahh that makes sense:

   "That will never change the current directory, since the popd is run in
a subshell."

So what's the possibility of adding -v option to popd and pushd???

-Pete

On Mon, Apr 17, 2017 at 1:33 PM, Chet Ramey  wrote:

> On 4/17/17 2:05 PM, Pete Smith wrote:
>
> > Using an alias solution:
> >
> >   popd | sed 's/\s/\n/g' | nl
> >
> > doesn't work, probably because they are shell built-ins.
>
> That will never change the current directory, since the popd is run in
> a subshell.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~
> chet/
>

Re: Issus with popd and pushd

[Pete Smith]

Am clearly out of my league in these exchanges about possible
implementation. Nevertheless am heartened by
seeing these exchanges.

As to the question that came up in the dialogue:

> Um... don't you mean to use the alias command somewhere, like:
>
> alias popd='builtin popd|tr " " "\n"'

I defined the alias in ~/.bash_aliases

>From one of your initial explanations: that points out that the alias would
be executed in a sub shell, it makes sense
to me that, that approach won't work.

It appears to me that the sub shell does inherit the dirs stack, but any
changes that are made to the dir stack remain
in the sub shell and do not propagate back to the parent shell.

I was thrown off track by:

alias dirs='dirs -v'

But after you explanation of the sub shell execution environment, this
makes sense as dirs does not make any changes
to the dirs stack.

Does the exchanges of your implementation comments mean the possibility of
the addition of the -v option to pushd and
popd are in the realm of possibility?

-Pete


On Tue, Apr 18, 2017 at 11:17 AM, Chet Ramey  wrote:

> On 4/18/17 2:13 PM, L A Walsh wrote:
> > Chet Ramey wrote:
> >> On 4/18/17 9:35 AM, Eduardo Bustamante wrote:
> >>
> >>
> >>> Or now that I think about it, you can get away with these functions:
> >>>
> >>> # masked builtins
> >>> dualbus@debian:~/foo/bar/baz$ pushd() { builtin pushd "$@" >/dev/null;
> >>> dirs -v; }; popd(){ builtin popd "$@" >/dev/null; dirs -v; }
> >>>
> >>
> >> This would be the preferable alternative, since it's so trivial.  The
> one
> >> change I would suggest would be to make the `;' a `&&':
> >>
> >> pushd()
> >> {
> >> builtin pushd "$@" >/dev/null && dirs -v
> >> }
> >>
> >>
> > Maybe add 'builtin' before "dirs" since we're redefining builtins
> > (i.e. get into habit?)
>
> Sure, if there's a chance there's a function named `dirs' and you *don't*
> want to use it, this is good practice.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~
> chet/
>

Re: Issus with popd and pushd

[Pete Smith]

Thanks

I was being a bit dense, didn't realize that the format you gave causes the
commands to run in the parent shell.

It works as it should!

-Pete

On Fri, Apr 21, 2017 at 10:52 AM, Chet Ramey  wrote:

> On 4/21/17 1:36 PM, Chet Ramey wrote:
>
> > I think the key takeaway is that this is trivial to do with a shell
> > function, even if you want to add argument parsing (use getopts) and
> > pass all the option arguments except -v to the builtins.
>
> On second thought, don't use getopts.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~
> chet/
>

Set command lists the shell variables and values, then lists other text (Script?)

[Pete Edwards]

/*)|[rs]pm|gif|jp?(e)g|mp3|mp?(e)g|avi|asf|ogg|class)"
[rview]="*.@([ao]|so|so.!(conf|*/*)|[rs]pm|gif|jp?(e)g|mp3|mp?(e)g|avi|asf|ogg|class)"
[galeon]="!*.@(?([xX]|[sS])[hH][tT][mM]?([lL]))"
[dillo]="!*.@(?([xX]|[sS])[hH][tT][mM]?([lL]))"
[fbxine]="!*@(.@(mp?(e)g|MP?(E)G|wm[av]|WM[AV]|avi|AVI|asf|vob|VOB|bin|dat|divx|DIVX|vcd|ps|pes|fli|flv|FLV|fxm|FXM|viv|rm|ram|yuv|mov|MOV|qt|QT|web[am]|WEB[AM]|mp[234]|MP[234]|m?(p)4[av]|M?(P)4[AV]|mkv|MKV|og[agmv]|OG[AGMV]|t[ps]|T[PS]|m2t?(s)|M2T?(S)|mts|MTS|wav|WAV|flac|FLAC|asx|ASX|mng|MNG|srt|m[eo]d|M[EO]D|s[3t]m|S[3T]M|it|IT|xm|XM)|+([0-9]).@(vdr|VDR))?(.@(crdownload|part))"
[oocalc]="!*.@(sxc|stc|xls?([bmx])|xlw|xlt?([mx])|[ct]sv|?(f)ods|ots)"
[harbour]="!*.@([Pp][Rr][Gg]|[Cc][Ll][Pp])"
[lodraw]="!*.@(sxd|std|sda|sdd|?(f)odg|otg)" [dvips]="!*.dvi"
[ps2pdf]="!*.@(?(e)ps|pdf)"
[kate]="*.@([ao]|so|so.!(conf|*/*)|[rs]pm|gif|jp?(e)g|mp3|mp?(e)g|avi|asf|ogg|class)"
[kid3-qt]="!*.@(mp[234c]|og[ag]|@(fl|a)ac|m4[abp]|spx|tta|w?(a)v|wma|aif?(f)|asf|ape)"
[pdftex]="!*.@(?(la)tex|texi|dtx|ins|ltx|dbj)"
[gvim]="*.@([ao]|so|so.!(conf|*/*)|[rs]pm|gif|jp?(e)g|mp3|mp?(e)g|avi|asf|ogg|class)"
[timidity]="!*.@(mid?(i)|rmi|rcp|[gr]36|g18|mod|xm|it|x3m|s[3t]m|kar)"
[ogg123]="!*.@(og[ag]|m3u|flac|spx)" [lzgrep]="!*.@(tlz|lzma)"
[ee]="!*.@(gif|jp?(e)g|miff|tif?(f)|pn[gm]|p[bgp]m|bmp|xpm|ico|xwd|tga|pcx)"
[unlzma]="!*.@(tlz|lzma)" [lbunzip2]="!*.?(t)bz?(2)"
[ooimpress]="!*.@(sxi|sti|pps?(x)|ppt?([mx])|pot?([mx])|?(f)odp|otp)"
[xine]="!*@(.@(mp?(e)g|MP?(E)G|wm[av]|WM[AV]|avi|AVI|asf|vob|VOB|bin|dat|divx|DIVX|vcd|ps|pes|fli|flv|FLV|fxm|FXM|viv|rm|ram|yuv|mov|MOV|qt|QT|web[am]|WEB[AM]|mp[234]|MP[234]|m?(p)4[av]|M?(P)4[AV]|mkv|MKV|og[agmv]|OG[AGMV]|t[ps]|T[PS]|m2t?(s)|M2T?(S)|mts|MTS|wav|WAV|flac|FLAC|asx|ASX|mng|MNG|srt|m[eo]d|M[EO]D|s[3t]m|S[3T]M|it|IT|xm|XM)|+([0-9]).@(vdr|VDR))?(.@(crdownload|part))"
[amaya]="!*.@(?([xX]|[sS])[hH][tT][mM]?([lL]))"
[gv]="!*.@(@(?(e)ps|?(E)PS|pdf|PDF)?(.gz|.GZ|.bz2|.BZ2|.Z))"
[kid3]="!*.@(mp[234c]|og[ag]|@(fl|a)ac|m4[abp]|spx|tta|w?(a)v|wma|aif?(f)|asf|ape)"
[lilypond]="!*.ly"
[modplug123]="!*.@(669|abc|am[fs]|d[bs]m|dmf|far|it|mdl|m[eo]d|mid?(i)|mt[2m]|oct|okt?(a)|p[st]m|s[3t]m|ult|umx|wav|xm)"
[pbzcat]="!*.?(t)bz?(2)" [unxz]="!*.@(?(t)xz|tlz|lzma)"
[playmidi]="!*.@(mid?(i)|cmf)" [lzcat]="!*.@(tlz|lzma)"
[slitex]="!*.@(?(la)tex|texi|dtx|ins|ltx|dbj)"
[aaxine]="!*@(.@(mp?(e)g|MP?(E)G|wm[av]|WM[AV]|avi|AVI|asf|vob|VOB|bin|dat|divx|DIVX|vcd|ps|pes|fli|flv|FLV|fxm|FXM|viv|rm|ram|yuv|mov|MOV|qt|QT|web[am]|WEB[AM]|mp[234]|MP[234]|m?(p)4[av]|M?(P)4[AV]|mkv|MKV|og[agmv]|OG[AGMV]|t[ps]|T[PS]|m2t?(s)|M2T?(S)|mts|MTS|wav|WAV|flac|FLAC|asx|ASX|mng|MNG|srt|m[eo]d|M[EO]D|s[3t]m|S[3T]M|it|IT|xm|XM)|+([0-9]).@(vdr|VDR))?(.@(crdownload|part))"
[advi]="!*.dvi" [lzmore]="!*.@(tlz|lzma)" )
postinst=/etc/post-install/07-pacman-key.post
__expand_tilde_by_ref ()
{
[[ -n ${1+set} ]] || return 0;
[[ $1 == REPLY ]] || local REPLY;
_comp_expand_tilde "${!1-}";
[[ $1 == REPLY ]] || printf -v "$1" "$REPLY"
}
__load_completion ()
{
_comp_load "$@"
}
__ltrim_colon_completions ()
{
_comp_ltrim_colon_completions "$@"
}
__parse_options ()
{
local -a _options=();
_comp_compgen_help__parse "$1";
printf '%s\n' "${_options[@]}"
}
_allowed_groups ()
{
_comp_compgen -c "${1:-$cur}" allowed_groups
}
_allowed_users ()
{
_comp_compgen -c "${1:-$cur

 last section entry to the file.

quote_readline ()
{
local REPLY;
_comp_quote_compgen "$1";
printf %s "$REPLY"
}
>>> command output ends.

This stuff looks to be an artifact of a bug and results in data at the end
of the output that is not part of the expected key value list and
therefore makes it harder to parse the shell variables and values.

$ bash --version
GNU bash, version 5.2.37(1)-release (x86_64-pc-msys)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>

Please advise?

Thank you

Pete Edwards

Use of arrows to scroll history list not same.

[pete Spam-Avoider]

Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linu
x-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/
share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H  -I.  -I. -I./include -I.
/lib   -g -O2
uname output: Linux parallax 2.6.11 #1 SMP Sat Apr 2 18:08:45 EST 2005 i686 unkn
own unknown GNU/Linux
Machine Type: i686-pc-linux-gnu

Bash Version: 3.0
Patch Level: 0
Release Status: release

Description:
In upgrading from bash-2.04 to bash-3.0 i'm experiencing a
change in the behaviour of the up/down arrow keys to scroll
through the history list of an interactive shell.  The 
behaviour for bash-2.04 was that i could scroll up from and 
then back down to a blank line.  For bash-3.0 if i scroll up
only one line and back down i can return to a blank line, 
however, if i scroll up more then one line then i can not
return to a blank line, instead some near random line of the
lines i had passed over remains at the prompt and not a blank
line.


Repeat-By:
Scroll up and down through the history list and see if
you can return down to a blank line.


 pete jordan
 x2164 at mailcity.com



-- 
___
NEW! Lycos Dating Search. The only place to search multiple dating sites at 
once.
http://datingsearch.lycos.com



___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash