Re: bash

user privileges (eg. root). Did you become root by either "su" or "su -"? If the former, then you'll have assumed root's UID without inheriting root's login environment and so not necessarily having /sbin on your path. In this scenario, OpenSUSE's version o

Re: bash

is utterly hateful. (For one thing, the > idea that there's a strong relationship between living in a */sbin > directory and requiring superuser privileges is clearly nonsense.) > > But the Bash source doesn't seem to contain relevant chunks of that > message, so I fear th

Re: bash

* Aaron Crane [2011-01-21 16:50]: > But the Bash source doesn't seem to contain relevant chunks of > that message, so I fear that, if you want to correctly > apportion blame, you should probably look elsewhere. Yes. My first instinct would be to indict SELinux. Regards, -- Arist

Re: bash

tween living in a */sbin directory and requiring superuser privileges is clearly nonsense.) But the Bash source doesn't seem to contain relevant chunks of that message, so I fear that, if you want to correctly apportion blame, you should probably look elsewhere. If I wanted to do that myself,

bash

Why do you think I became root? # id uid=0(root) gid=0(root) groups=33(video),100(users) # yast2 sw_single Absolute path to 'yast2' is '/sbin/yast2', so running it may require superuser privileges (eg. root). If that were in . I'd understand and appreciate, but this is so silly -- H.Merijn Bra

Re: Printing text in DOS (Re: bash)

On 6 December 2010 22:31, Joshua Juran wrote: On Dec 6, 2010, at 7:19 AM, Aristotle Pagaltzis wrote: * Peter da Silva [2010-11-29 00:05]: What wrong direction was chosen in 1969? Leaving terminal support entirely up to userspace, via libraries? The only worse clusterfuck that comes to mi

Printing text in DOS (Re: bash)

On Dec 6, 2010, at 7:19 AM, Aristotle Pagaltzis wrote: * Peter da Silva [2010-11-29 00:05]: What wrong direction was chosen in 1969? Leaving terminal support entirely up to userspace, via libraries? The only worse clusterfuck that comes to mind from own experience was printing under DOS.

Re: bash

Hi, On Mon, Dec 06, 2010 at 01:04:47PM -0600, Peter da Silva wrote: > Printing under UNIX used to be pretty good when you could depend on the > printer actually implementing Postscript. Which basically meant "offload all the printing intelligence somewhere else so unix printing doesn't have to b

Re: bash

Printing under UNIX used to be pretty good when you could depend on the printer actually implementing Postscript. Printers (and winprinters) are a whole new hate.

Re: bash

Hi, On Mon, Dec 06, 2010 at 05:39:09PM +, Peter Corlett wrote: > Isn't printing under Unix bad enough? Now *that* is worth a completely new rant. (Don't even get me started on chromium's "print" feature that makes things even worse than normal unixish printing). gert -- USENET is *not* th

Re: bash

On Mon, Dec 06, 2010 at 04:19:54PM +0100, Aristotle Pagaltzis wrote: > [...] You get fun times if you do things such as start a program under an > rxvt-unicode terminal and reattach it under a putty-256color one. Er, can you even do that on Unix without the likes of screen or tmux? > You can work

Re: bash

On 2010-12-06, at 09:19, Aristotle Pagaltzis wrote: * Peter da Silva [2010-11-29 00:05]: On 2010-11-28, at 15:35, Aristotle Pagaltzis wrote: It is not a bug. It is the place we have arrived after years of walking down the path that followed the wrong direction chosen from the start. I am not

Re: bash

On Mon, 6 Dec 2010, Aristotle Pagaltzis wrote: > * Peter da Silva [2010-11-29 00:05]: > > > > What wrong direction was chosen in 1969? > > Leaving terminal support entirely up to userspace, via libraries? Of course the kernel-mode parts of terminal handling are not a clusterfuck at all, oh no. T

Re: bash

* Peter da Silva [2010-11-29 00:05]: > On 2010-11-28, at 15:35, Aristotle Pagaltzis wrote: > > It is not a bug. It is the place we have arrived after years > > of walking down the path that followed the wrong direction > > chosen from the start. I am not complaining about the hack > > itself. > >

Re: bash

On 2010-11-28, at 15:35, Aristotle Pagaltzis wrote: > It is not a bug. It is the place we have arrived after years of > walking down the path that followed the wrong direction chosen > from the start. I am not complaining about the hack itself. What wrong direction was chosen in 1969?

Re: bash

On Fri, Nov 26, 2010 at 08:11:23PM -0800, Aaron J. Grier wrote: [...] > are there any OSes where the serial API actually hid the UART(s) and > wasn't so hateful? I don't recall AmigaOS's API being particularly hateful: it was effectively a character device with some OOB commands to set the paramet

Re: bash

the other hand im worried I wont know which > unbreak-me-harder I will need to know :-) Under some combinations of PuTTY/urxvt/SSH/whathaveyou (I never got as far as figuring out what exactly is going on), hitting Ctrl-L in bash won't clear the screen as I'm used to. I got tired o

Re: bash

* Peter da Silva [2010-11-28 17:05]: On 25 October 2010 21:25, Aristotle Pagaltzis wrote: >My very most favourite recent addition is > bind -x ’“\C-l”: clear’ >which ultimately goes all the way back to how stupidly >terminals were bolted onto the side of Unix. Excuse me while >I bang my head o

Re: bash

On 25 October 2010 21:25, Aristotle Pagaltzis wrote: My very most favourite recent addition is bind -x ’“\C-l”: clear’ which ultimately goes all the way back to how stupidly terminals were bolted onto the side of Unix. Excuse me while I bang my head on this desk. A hack to duplicate an obsol

Re: bash

On 25 October 2010 21:25, Aristotle Pagaltzis wrote: * Tony Finch [2010-10-19 12:30]: D'oh! That explains why I never see this stupidity. 1.1 (fanf 01-Sep-99): shopt -s cdspell checkhash checkwinsize extglob histappend It almost seems like half my .bashrc is unbreak-me-harder crud. My very

Re: bash

On 18 October 2010 17:30, Peter Corlett wrote: > My least favourite shell feature is the context-ignorant globbing and > expansion. Hear hear. rm *.foo failing because there are too many files? Very useful. Especially in an emergency when something is spewing our *.foo files like crazy -- p

bash

Dear bash, Why do you insist on hashing the paths to commands. And never expiring the cache. Or detecting that it has gone stale. In this day and age, of more RAM and CPU than we know what to do with? How hard would it be to record the device, inode and mtime of each entry in PATH, and

Re: bash

On Mon, Oct 25, 2010 at 09:25:55PM +0200, Aristotle Pagaltzis wrote: > which ultimately goes all the way back to how stupidly terminals were > bolted onto the side of Unix. Excuse me while I bang my head on this > desk. > > Agh, agh, agh, agh, agh???, termios. hee hee. of course windows' serial

Re: bash

* Tony Finch [2010-10-19 12:30]: > D'oh! That explains why I never see this stupidity. > > 1.1 (fanf 01-Sep-99): shopt -s cdspell checkhash checkwinsize extglob > histappend It almost seems like half my .bashrc is unbreak-me-harder crud. My very most favourite recent addition is bind -x '"

Re: bash

On Tue, Oct 19, 2010 at 11:30:42AM +0100, Tony Finch wrote: > On Tue, 19 Oct 2010, Daniel Pittman wrote: > > > > So, instead, we have 'set -o checkhash' to ask it to please work like sane > > people expect. > > D'oh! That explains why I never see this stupidity. > > 1.1 (fanf 01-Sep-99): shopt -s

Re: Out of Office AutoReply: bash

Talking about hateful software...: On Wed, Oct 20, 2010 at 11:21:44PM +1300, Nigel Tidswell wrote: > I am on leave, and will be back at work Tuesday 2 November. > > For urgent enquiries please ring (06) 873 7550 > > Nigel Tidswell > > > _

Re: bash

On 2010-10-19, at 05:30, Tony Finch wrote: My favourite shell hate is POSIX's "logical" cd behaviour. And I see that POSIX does not have the "don't be stupid" option `set -o physical`. Augh. What, you mean where "cd .." does a string operation on $CWD instead of just following ".."? I can see

Re: bash

On Tue, 19 Oct 2010, Daniel Pittman wrote: > > So, instead, we have 'set -o checkhash' to ask it to please work like sane > people expect. D'oh! That explains why I never see this stupidity. 1.1 (fanf 01-Sep-99): shopt -s cdspell checkhash checkwinsize extglob histappend > Which, of course, acco

Re: bash

On Tue, 2010-10-19 at 08:18 +0200, H.Merijn Brand wrote: > On Tue, 19 Oct 2010 10:02:38 +1100, Daniel Pittman > wrote: > > What I find hateful is the "Don't Be Stupid" switch. Which, naturally, the > > developers of bash supplied because you wouldn't want t

Re: bash

Bash lets me work every day, despite its shortcomings. Just start me on Finder. Neil PS and top posting. On 19 Oct 2010, at 00:02, Daniel Pittman wrote: Nicholas Clark writes: Dear bash, Why do you insist on hashing the paths to commands. And never expiring the cache. Or detecting that

Re: bash

On Tue, 19 Oct 2010 10:02:38 +1100, Daniel Pittman wrote: > Nicholas Clark writes: > > > Dear bash, > > > > Why do you insist on hashing the paths to commands. > > And never expiring the cache. > > Or detecting that it has gone stale. > > In this day

Re: bash

Nicholas Clark writes: > Dear bash, > > Why do you insist on hashing the paths to commands. > And never expiring the cache. > Or detecting that it has gone stale. > In this day and age, of more RAM and CPU than we know what to do with? > > How hard would it be to reco

Re: bash

On 2010-10-18, at 10:30, Peter Corlett wrote: Er... oh, fuck it, why didn't Linus come up with a VMS clone instead? Because nobody would have given a shit. A company did come up with a cheap VMS clone for PCs back in the '80s, and didn't get any sales until they ported a UNIX compatibility la

Re: bash

On Mon, Oct 18, 2010 at 09:18:36AM -0700, Joshua Juran wrote: [...] > But if you want to use classic Mac OS (or any other OS) *without* a POSIX > layer, then be my guest. I used to use AmigaOS, which wasn't all that bad. You could spot the stuff ported from Unix using an emulation layer because it

Re: bash

On 2010-10-20, at 05:19, Peter Corlett wrote: Sure, it was hateful in its own special ways, but it was no less usable than a Unix system of similar vintage. I'm a big fan of the Amiga and its design, but if I could have bought something like a 3b1 for the price of an Amiga it wouldn't have sto

Re: Debian Bash Command-Not-Found Extension

On Fri, 4 Jan 2008, Peter da Silva wrote: > > It does actually say that it's the name of a function, not a variable, but > putting it in the shell variable section seems pretty hateful, yes. It implies it's a variable containing the name of a function. It should just say that it is a shell functio

Re: Bashing Bash Hashing

Phil Pennock wrote: > On 2008-01-04 at 16:07 -0800, Michael G Schwern wrote: >> Of course, as Peter insinuated, I'm sure by now it's been rationalized as a >> "feature". > > In large environments, having everything always locally available on > local disk is fairly recent, with cluster management

Re: Debian Bash Command-Not-Found Extension

On 2008-01-04, at 18:43, Phil Pennock wrote: ObHate: These two don't produce the same result: $functions['foo bar'] x='foo bar'; $functions[$x] I think I know why, and if so that's probably the only "C" like feature in csh. Typical that zsh would decide that was something to inherit fro

Re: Debian Bash Command-Not-Found Extension

On 2008-01-04 at 20:33 +, Aaron Crane wrote: > Also, I decided I didn't care about any brokenness resulting from > however the user might have managed to persuade the shell to create a > function with a non-identifier-syntax name. After all: > > $ foo\ bar() { echo bla

Re: Bashing Bash Hashing

On 2008-01-04 at 16:07 -0800, Michael G Schwern wrote: > Of course, as Peter insinuated, I'm sure by now it's been rationalized as a > "feature". In large environments, having everything always locally available on local disk is fairly recent, with cluster management systems etc. NFS is still com

Re: Bashing Bash Hashing

Smylers wrote: > I just spotted this in the README.Debian that Debian supply with Bash: > > bash does not check $PATH if hash fails > > bash hashes the location of recently executed commands. When a command > is moved to a new location in the PATH, the command is still i

Re: Debian Bash Command-Not-Found Extension

On 2008-01-04, at 14:33, Aaron Crane wrote: It's not necessary to quote a variable on the right-hand side of an assignment: $ f() { local x=$1; echo "[$x]"; } $ f 'foo bar' [foo bar] I'm not sure I entirely approve of that, because it seems to make the syntax less regular, and I'll c

Re: Debian Bash Command-Not-Found Extension

ght-hand side of an assignment: $ f() { local x=$1; echo "[$x]"; } $ f 'foo bar' [foo bar] Also, I decided I didn't care about any brokenness resulting from however the user might have managed to persuade the shell to create a function with a non-identifier-sy

Re: Debian Bash Command-Not-Found Extension

On Jan 4, 2008 2:50 PM, Aaron Crane wrote: > Peter da Silva writes: > > Unfortunately there doesn't seem to be a way to rename functions in > > bash. > > I beg to differ. > > function rename_function { > local old=$1 new=$2 > eval &

Re: Debian Bash Command-Not-Found Extension

On 2008-01-04, at 13:50, Aaron Crane wrote: function rename_function { local old=$1 new=$2 eval "$(declare -f $old | sed "1s/^$old/$new/")" unset -f $old } Neat trick! I would make that "1s/^$old /$new /" myself, and quote "$old" and "$1" and so on...

Re: Debian Bash Command-Not-Found Extension

Peter da Silva writes: > Unfortunately there doesn't seem to be a way to rename functions in > bash. I beg to differ. function rename_function { local old=$1 new=$2 eval "$(declare -f $old | sed "1s/^$old/$new/")" unset -f $old } -- Aaron Crane

Re: Debian Bash Command-Not-Found Extension

On 04/01/2008, Juerd Waalboer wrote: > Smylers skribis 2008-01-04 18:30 (+): > > The program 'rot13' is currently not installed. You can install it by > > typing: sudo apt-get install bsdgames > > bash: rot13: command not found > > I haven't

Re: Debian Bash Command-Not-Found Extension

Smylers skribis 2008-01-04 18:30 (+): > The program 'rot13' is currently not installed. You can install it by > typing: sudo apt-get install bsdgames > bash: rot13: command not found I haven't tried or even wanted to change the feature yet, but I must say, even t

Re: Debian Bash Command-Not-Found Extension

ion and call it from the new. Unfortunately there doesn't seem to be a way to rename functions in bash.

Re: Bashing Bash Hashing

On Fri, Jan 04, 2008 at 07:09:04PM +0100, demerphq wrote: > Heh. I got bit by this hatefulness for the first time just yesterday. > Very confusing. Its nice to hear I'm not the only one who finds this > stupidity to be, er, stupid. It's particularly hateful because when you run "rehash" to fix it,

Re: Bashing Bash Hashing

On 4 Jan 2008, at 18:39, Walt Mankowski wrote: It's particularly hateful because when you run "rehash" to fix it, it returns instantaneously. I wonder if this is a case of premature optimization, or if it's a relic of bygone days when CPUs and hard drives were a lot slower. I assume hash -r j

Re: Bashing Bash Hashing

Yes, this is one of those things that pisses me off about csh too. It's something that was done back when it was running on a PDP-11 and the four or five extra calls to namei() that you'd get when you typoed a command were significant on a machine with 70 users, 2MB of RAM, and big slow 14"

Debian Bash Command-Not-Found Extension

Debian/Ubuntu supply Bash with an extension that lets you define a function to be run whenever a command in an interactive shell hasn't been found. As shipped it does things like this, which can be handy: $ echo znetnerg gungpure | rot13 The program 'rot13' is currently not

Re: Bashing Bash Hashing

On 04/01/2008, Smylers wrote: > I just spotted this in the README.Debian that Debian supply with Bash: > > bash does not check $PATH if hash fails > > bash hashes the location of recently executed commands. When a command > is moved to a new location in the PATH, the comma

Bashing Bash Hashing

I just spotted this in the README.Debian that Debian supply with Bash: bash does not check $PATH if hash fails bash hashes the location of recently executed commands. When a command is moved to a new location in the PATH, the command is still in the PATH but the hash table still records

Re: Feisty or Bash hate

* Robert Rothenberg [2007-04-27 00:55]: > On 26/04/07 05:04 A. Pagaltzis wrote: > > Wow. So what new way of writing the following do they > > propose? > > > > if [[ $string =~ ' foo ' ]] ; then ... > > Apparently it's > > if [[ $string =~ \ foo\ ]] ; then ... I expected that answer.

Re: Feisty or Bash hate

On Apr 26, 2007, at 5:52 PM, Robert Rothenberg wrote: if [[ $string =~ \ foo\ ]] ; then ... That's just wrong. I mean, it's correct syntax, but it's wrong to have to use that syntax exclusively instead of quoting.. What is their logic?

Re: Feisty or Bash hate

On 26/04/07 05:04 A. Pagaltzis wrote: > Wow. So what new way of writing the following do they propose? > > if [[ $string =~ ' foo ' ]] ; then ... Apparently it's if [[ $string =~ \ foo\ ]] ; then ... which looks to my Perl-stained eyes like / foo/ (no trailing whitespace). Non-denu

[offlist] Re: Feisty or Bash hate

Pity rc didn't take off.

Re: Feisty or Bash hate

* Phil Pennock [2007-04-26 06:30]: > ObHate: zsh may be powerful but the extended syntax can > sometimes make Perl JAPH hacks look like elegant models > of clean design. Shells inherently blow. Now if only they weren't also so damn useful... Regards, -- Aristotle Pagaltzis //

Re: Feisty or Bash hate

On 2007-04-25 at 15:33 +0100, Robert Rothenberg wrote: > In Bash 3.2, the syntax of regular expressions were changed. So > > if [[ $string =~ 'foo(.*)' ]] then ... I like that =~ operator. In zsh, you zmodload zsh/pcre and then use the -pcre-match operator, thus: if [[

Re: Feisty or Bash hate

* Robert Rothenberg [2007-04-25 16:40]: > In Bash 3.2, the syntax of regular expressions were changed. So > > if [[ $string =~ 'foo(.*)' ]] then ... > > should become > > if [[ $string =~ foo(.*) ]] then ... > > You can imagine how many scripts

Re: Feisty or Bash hate

On Apr 25, 2007, at 9:33 AM, Robert Rothenberg wrote: In Bash 3.2, the syntax of regular expressions were changed. So if [[ $string =~ 'foo(.*)' ]] then ... should become if [[ $string =~ foo(.*) ]] then ... You can imagine how many scripts that breaks. OK, I can see no good

Feisty or Bash hate

I'm not entirely sure which one of these to hate, so I think I'll spread it evenly and hate both of them. In Bash 3.2, the syntax of regular expressions were changed. So if [[ $string =~ 'foo(.*)' ]] then ... should become if [[ $string =~ foo(.*) ]] then ... You

Re: Bash file completion, symbolic links and pwd confusion

Is software any less hateful just because other software is hateful as well?

Re: Bash file completion, symbolic links and pwd confusion

On Thu, 1 Feb 2007, Peter da Silva wrote: > Bash is doing the wrong thing. It's not a bash bug, it's a posix bug. BSD sh and ksh will do the same broken thing by default. Tony. -- f.a.n.finchhttp://dotat.at/ ROCKALL MALIN: WESTERLY OR SOUTHWESTERLY 5 OR 6, OCCASIONALLY 7, DECR

Re: Bash file completion, symbolic links and pwd confusion

I think you'll find that if you scratch the Made in China sticker off your sunglasses, it says Hecho en Mexico, dude. http://www.achewood.com/index.php?date=07312006 On 2/2/07, Peter da Silva wrote: Bash is doing the wrong thing. You are in "foo/bar". There is nothing insid

Re: Bash file completion, symbolic links and pwd confusion

Bash is doing the wrong thing. You are in "foo/bar". There is nothing inside "foo/bar" for any program you run to tell that you got there by following a symbolic link. Bash is hiding this from you. This is like getting on a plane and having it fly to the wrong airport, and

Re: Bash file completion, symbolic links and pwd confusion

You can turn off this POSIX-me-harder braindamage with set -P. Tony. -- f.a.n.finchhttp://dotat.at/ VIKING: WEST, BACKING SOUTHWEST FOR A TIME, 4 OR 5 OCCASIONALLY 6. MODERATE OR ROUGH. OCCASIONAL RAIN OR DRIZZLE. GOOD, OCCASIONALLY MODERATE OR POOR.

Bash file completion, symbolic links and pwd confusion

Note the following session: m...@nix:~$ mkdir foo m...@nix:~$ mkdir foo/bar m...@nix:~$ mkdir foo/feh m...@nix:~$ mkdir baz m...@nix:~$ mkdir baz/bo m...@nix:~$ cd baz m...@nix:~/baz$ ln -s ../foo/bar m...@nix:~/baz$ cd bar m...@nix:~/baz/bar$ ls ../bo Bash file completion works as one