Re: If Luicd ia a LTS......
On 2010-03-23 at 11:05:44 +, Dmitrijs Ledkovs wrote: > Hardy -> Lucid upgrade will not be enabled on day 0. Latest plans I've > read (maybe changed since then) is that LTS upgrade will start with > 10.04.1 which will bring us a few bugfixes after the release. > So you should consider Lucid to become LTS with 10.04.1 That sounds like the route we have to take with Microsoft. Wait until Vista SP1. Wait until 7 SP1. Wait until SP1. It's good to see Ubuntu handling 'slipping' deadlines by rushing code out the door and saying "We'll fix it in the next service pack". ;) In all seriousness, this is only Beta 1. If we hit the RC and my Intel graphics are still screwed up and plymouth doesn't work...maybe then it's time to be worried. -A -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Standing in the street trying to hear yourself think
> As soon as more than x people actively seeking help are on a channel (not > sure how many in this case), it becomes hard for new people on the channel > to get attention. The trick would be to get the volunteers onto the right > subchannel so that when someone on #ubuntu points the user to #ubuntu-sound, > there are a couple of people on #ubuntu-sound to help them. Otherwise, > they'll just go back to #ubuntu and start complaining. One of the sites that has become very successful (IMO) in the IT world is the experts-exchange site. The model they have setup works very well because it's a reward-based system and everyone can benefit from the answers just scroll down to the very bottom of the page... ;) One way of applying this to IRC would be similar to what you said. Have #ubuntu where everyone comes in to ask their questions and get redirected. Have a few channels that everyone can join. #ubuntu-general #ubuntu-networking #ubuntu-install etc... You might join #ubuntu and ask why your NIC isn't working. Someone will redirect you to #ubuntu-networking to get your problem fixed. If no one in #ubuntu-networking can figure out the problem, they can have someone in #ubuntu-networking-level-2 send the user an invite to join the 'level 2' channel for support. People who are very proficient with networking would be in the level 2 channel. The only way to become a tech in the level 2 channel would be to spend time in #ubuntu-networking and demonstrating that you 'know your stuff'. Level 2 channels would be invite only so tech won't have to reply 'Did you kick your network cable out?' I believe a situation like this would be beneficial both to end-users and support people. End users would have a place to go and ask questions. If they can't get an answer, they get passed up to higher level and more experiences techs. >From the tech standpoint, it is somewhat a badge of honor to be a level 2 >tech. You have the benefit of being recognized as someone knowledgeable, and >you also don't have to wade through the 'Is the network cable plugged in?' >type questions that would come through the level 1 channels. Personally, I never join #ubuntu to help out. There's no benefit to me, but there *is* a huge headache of trying to wade through the flood. ...but I would put in my time so I can become a level 2 tech because I love working on tough network issues. The idea could potentially be applied in a forum situation where people can ask questions and give points for fixing the problem... That's just my thoughts. -A -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Bug 157909: Unbootable system, affects many, apparently ignored
Thank you for replying Markus. This is the first time I've heard the term AHCI. I did some googling and read up on it. From what I understand, AHCI is a mode you can set in the BIOS. I dug through the system BIOS and the BIOS on both cards and found no such setting. The cards are extremely cheap soft-RAID cards that I purchased simply so I could get 8 400GB SATA drives into my server case. So to answer "What stops you from switching to AHCI?" I would have to say to things: 1. No clue how to enable AHCI 2. If it's a BIOS setting, it appears my cards don't support it. -Aaron > Am 25.12.2007 um 23:35 schrieb Aaron C. de Bruyn: > >> Can anyone provide me with some guidance on how to resolve this issue? Am >> I overblowing the issue since I am affected? > > Just to understand the problem better: > > Exposing SATA drives as IDE drives to the OS appears to be a temporary > solution until all SATA driver programmers ( Hello Intel :-) ) have catched > up and made an AHCI driver available. Ubuntu runs in AHCI mode just fine, > even on a board which lacks a proper driver for Windows XP. AHCI is > noticeable faster than IDE. > > What stops you from switching to AHCI? > > > Markus > > - - - - - - - - - - - - - - - - - - - > Dipl. Ing. Markus Hitter > http://www.jump-ing.de/ > > > > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Bug 157909: Unbootable system, affects many, apparently ignored
I would like some feedback from the community, as I am somewhat a noob in how to handle this. Bug 157909 (https://bugs.launchpad.net/ubuntu/gutsy/+source/linux-source-2.6.22/+bug/157909) deals with a recent change to the kernel config. A new config switch was added CONFIG_IDE_MAX_HWIFS, and someone decided to give it an arbitrary value of 4. This variable apparently means the kernel only allocates space for 4 IDE devices. Assuming a system with a primary and secondary IDE port on the motherboard, this would be fine. But it also affects the server kernel. Any my server has to SATA cards it in, along with onboard SATA, and two IDE interfaces. One of the SATA cards exposes the drives as IDE. So I have a total of 8 IDE drives in my system. Because of this seemingly arbitrary value, my system won't boot. Half the drives are unavailable. Anyways--there are a few people on the list who are suffering from this issue besides me. Any everyone 'higher up' has listed fixing this as a 'wishlist' item, an 'invalid' request, or 'fixed' in Hardy. Maybe I'm wrong, but shouldn't something this serious be fixed in the CURRENT version of ubuntu. I feel this has a serious impact. In order to get my system working, I had to figure out how to compile a kernel 'The Ubuntu Way' (http://www.howtoforge.com/kernel_compilation_ubuntu) and install my own kernel. I'm not sure about anyone else in the bug, it may be beyond them how to get it fixed. Can anyone provide me with some guidance on how to resolve this issue? Am I overblowing the issue since I am affected? Would fixing this violate the SRU (https://wiki.ubuntu.com/KernelUpdates) as someone states in comment 13 (https://bugs.edge.launchpad.net/ubuntu/gutsy/+source/linux-source-2.6.22/+bug/157909/comments/13)? Should I just use my own kernel until Gutsy comes out? Thanks for reading. Merry Christmas. -Aaron -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: fsck on boot is major usability issue
> Of course then there's the laptop angle. > My old POS laptop has about 3 minutes of battery life left. One day I either > need a new laptop or to pony up a thousand for a shiny new model. > Anyways--I usually hit shutdown, unplug everything and throw it in my bag. > > It would definitely run out of juice before the check was done on my 120 GB > drive. > > -A Doh. My bad. Totally missed the whole part of the thread discussing exactly what I just said. -A -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: fsck on boot is major usability issue
> My personal preference would be to move it to shut-down, but an > interruptable check on boot is better than nothing. Just my two cents. Of course then there's the laptop angle. My old POS laptop has about 3 minutes of battery life left. One day I either need a new laptop or to pony up a thousand for a shiny new model. Anyways--I usually hit shutdown, unplug everything and throw it in my bag. It would definitely run out of juice before the check was done on my 120 GB drive. -A -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GIMP *final* release for Gutsy?
> Aaron C. de Bruyn: > > It boils down to this: If users aren't running into bugs, why repackage? > > Because having “Release Conadidate” on the splash screen and “rc” in the > About box gives users the impression that this is not a trustworthy, > final version of GIMP. Kinda like how hundreds of thousands of people used the old ICQ 99b (or whatever the version was) client that was listed as a 'beta' for years. ...or how people used the beta version of gmail. I honestly didn't notice that GIMP said "Release Candidate" on the splash screen until this discussion came up, and I use it daily. My wife also uses it daily, and she's not a geek like me--just a home user. She never realized it either. Maybe we're just completely oblivious. But I think most people won't care what it says--they'll just run it. ...of course someone else pointed out that it actually says "Release Conadidate" instead of 'candidate'. Heck--I missed that too. But that's something that should be fixed. Just because it says Beta or Release Candidate or isn't a final version is not a reason to update the package. Even the final, officially approved, non release candidate version will have bugs. ...and they will have to be fixed. So why not just fix the bugs when they are reported. I'm not trying to be a jerk--I just don't see the point in updating because of the version string. I do see a point in updating due to a bug. -A -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GIMP *final* release for Gutsy?
> I often report it to both Ubuntu and Upstream. Things tend to get fixed > more quickly that way. Ubuntu bugs can sit for *months* (and even over a > year) untouched. I have run into similar issues. I am being affected by a bug on my server that prevents it from seeing all my drives. The change requires recompiling the kernel with 1 line changed. It's pretty major, but the bug sat for 2-3 weeks. So rather than me constantly complaining, I set a goal for myself. Get involved with triaging bugs. Once I have that down, learn packaging and start packaging apps for Ubuntu. You should understand that the community you are dealing with is volunteer and accept that you don't dictate how the community is run or how they provide services to you. Right now you're just blowing a lot of hot air around and telling a bunch of volunteers to get stuff doneand in my opinion it's kinda like herding cats. If you want it changed pick one of the following: * Go buy support from someone (like Canonical) and have them change it * Learn to change it yourself * Post a bug report if you are having an issue and let the community deal with it as they are able -A > But if a package was buggy (notably those in Universe) in the previous > release of Ubuntu and wasn't causing problems/conflicts with any other > package, it's bumped up to the next release "as is" (with all bugs in tact). > > So much for "QA". Universe is an entirely different animal than the main repos. I don't remember the exact warning, but my system warned me when I enabled universe saying that it contained packages that hadn't gone through the rigorous QA the main packages went through. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GIMP *final* release for Gutsy?
> And how do you know that no one is having a problem? Oboviusly > *somebody* is or the latest release would not be 4.0.1. Bug reports. If someone is having a problem and they file a bug report, it will get dealt with. > And just becasuse Ubuntu users haven't reported the bugs that the GIMP > devs cite, doesn't mean they don't exist. So you are saying that we should react to new versions by packaging the up on the basis that there are probably users that could maybe be having bugs but haven't reported them. I'm sure by now just about every package in Gutsy has an updated version. It would take a *TON* of development time constantly updating packages. We react to problems (bug reports), we don't react to 'what ifs' (users possibly having problems but not reporting them). > And lastly, what are the Ubuntu devs *developing* in the case of > compiling existing source code from the GIMP? As far as I can tell > there is nothing different between the version of the GIMP shipped with > Ubuntu Feisty as there was with Fedora 7 (both now *old* Linux distros). Sorry--that didn't make much sense to me. Are you saying that the developers aren't really doing anything except packaging and compiling? (i.e., not actually writing GIMP, just packaging) Yeah? So? I've spent this weekend trying to package an application I wrote with no prior packaging experience. I'm still working on it. Now I'm sure seasoned packagers can repackage GIMP in 30 minutes, but it's still 30 minutes being taken away from getting the next release ready for a knee-jerk 'what if' reason. Combine that with the thousands of packages out there waiting for updates and you are talking about a lot of man-hours. -A -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GIMP *final* release for Gutsy?
> > Upgrading simply because there is a newer version number is the wrong > > attitude. > > I agree. And if this were about 4.0 to 4.1 or 4.3 to 4.7, I would be > 100% with you. So you agree that upgrading because a change in the MINOR version number or BUILD number is the wrong attitude. > But this is not the case. Ubuntu shipped with a *pre-release* version of ...and then you go on to say that a change in the MINOR or BUILD version is grounds to upgrade. You are contradicting yourself. And you still haven't answered the question about bugs. Are you running into a bug in the release candidate that is causing you issues? If no, there is no point in taking dev time away from something else. If yes, we should have a bug report filed and a developer looking at it. > the GIMPs site you'll note that there are *numerous* bugfixes already > in the .1 release (not unusual .0 releases are notoriously buggy - in > any program). Right, so they fixed bugs. And you are asking us to repackage GIMP simply because they have fixed bugs. So what about next week when they fix more bugs? Time to repachage again? There are always going to be bugs. It's simply a matter of people running into the bugs or not. So once again--are you having a specific issue? > But even if it were 100 bug-free. We're not talking about just a simple > version number change here Yes, we are. x.y-RC to x.y That's a simple change. x.y-RC to x.y+1 is a simple change too. It boils down to this: If users aren't running into bugs, why repackage? -A -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GIMP *final* release for Gutsy?
> Aaron C. de Bruyn: > > Upgrading simply because there is a newer version number is the wrong > > attitude. > > It's not that fact that it's a newer version (number): it's that it's a > final, stable release versus a non-final non-stable release. And what makes a release stable or non-stable? The version number? No. It's the code that goes into it. So unless you are running into a bug, there is no need to take a developer away from working on Gutsy to have him fix a problem that no one is having. -A -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GIMP *final* release for Gutsy?
> Wouldn't logic dictate that if their latest release was for bugfixes, > that they would recommend an update? Or do developers update software > "just for the heck of it"? I haven't done an official study or anything, but I'd be willing to bet that a month after Gutsy is out, about half the packages are out-of-date if you look at version numbers. So what? Upgrading simply because there is a newer version number is the wrong attitude. If we followed that practice, the devs would be spending all their time trying to keep the Gutsy packages up to date instead of working on Hardy. If you run into a specific bug, post a bug report and if a newer version of GIMP fixes your issue, someone will get it into the repo. Personally, I use GIMP every day--but I am not affected by any of those bugs, so I don't care if they upgrade or not. If you are affected, file a bug report. -A -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: A tricky situation in malone bug 60995
> It's the wrong way to fix it. You can lose data by clicking enter > while a link is focused too, should we disable the enter key? The Your example doesn't fit. Navigation is the PRIMARY function of the enter key. Enter is for submitting URLs in the location bar, for following links, and submitting forms, and in other parts of the computer opening files, and signaling the end of commands. It's function is navigation. It signals that you want to activate some action. The only place where enter isn't used for navigation is in a textarea field. And if you're accidentally in a textarea and hit enter instead of over a link or submit button, you don't lose data. In the inverse, you're talking about making backspace edit text in some instances, and navigate in others when it's PRIMARY function is editing data. Potentially through a very common user error (not being in a text field when hitting backspace), users could lose data. It's sorta a pattern we rely on when using computers. Arrow keys?Navigation around a page, navigation around history, navigation around text, etc... Enter key? Navigation to a different URL, navigation via hyperlink, navigation by submitting form data... Page up/down? Navigation around a page. Alpha keys? Entering data. Numeric keys?Entering data. Backspace key? Deleting data. Delete key? Deleting data. Put in an option to turn it on if you want it, but I wouldn't enable it by default. -A -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: A tricky situation in malone bug 60995
> Maybe you mean that you "switched from Windows to Linux for.." because > Firefox on Windows has always used BACKSPACE==BACK. Also, I agree that > reversability is very important in GUIs (being smart about "confirms" and > providing good undo where it makes sense). Hmm--I never ran into my most annoying issue of hitting backspace to delete text and it getting confused. I was only on firefox for windows for a month before I switched to Linux--so I may not have even had the opportunity to run into the issue. -A -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: A tricky situation in malone bug 60995
> I installed Ubuntu just yesterday, and backspace not mapping to 'back > in history' is the main annoying thing I found. It happened once or > twice (in a year) that I went one page back when I wanted to delete > text, because I wasn't focused on the right control. But I'd > definitely choose the slight possibility of dataloss in that > particular case, over having backspace duplicate the page up key > (they're close enough on the keyboard!) instead of Alt-Left (which is > a really uncomfortable keystroke). I switched from IE to Firefox for three reasons: 1. Tabs rock 2. Open source rocks 3. Not suddenly finding myself 5 pages back in my history rocks. I would type something in wrong like my password into a webform and hit backspace a few times to correct it. From time to time, IE would occasionally freak out thinking I wasn't in a text box or something and suddenly I'd find myself 5 pages back in my history. My guess is someone messing around with .setfocus() or whatever the heck the javascript command is. About half the time, the data I entered in my form would be lost. Sometimes it would be my fault though. I'd be filling in a long form, tabbing between fields, and there'd be a link between one set of fields. I'd either tab on to the link and start typing and (not looking at the screen) realized I mistyped a key and hit backspace, or I would tab past the link, start typing, realize I screwed up the field before the link, hit SHIFT+TAB to go back and correct it (forgetting about the link), hit backspace to clear the contents of the field--and suddenly I'm back a page in my history. Once again, I would occasionally lose my form data with this. Now maybe firefox is better at saving the form data (I don't pay much attention when it does get saved, just when it gets lost). And maybe firefox won't be stupid like IE and get confused about backspacing text verses going back a page in history, but I personally feel that backspace is a function related to text. If you want to go back a page in firefox, use something like ALT+Left Arrow. But the argument can be avoided altogether. Maybe an option should be added so people can turn on using backspace as a navigation key. -A -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Restricted tab-completion is annoying
> > I too find the programmable completion very annoying. > > And I find them very useful, except where they have bugs (e.g. "sudo > -e", which should work like 'sudoedit'). IMHO tab-completion should > complete to what's supposed to be there in most cases, maybe even giving > hints if there is a choice between several types of "data" (e.g. options > vs. filenames; where the former start with "-" or "--"). > > OTOH, I think applications should ideally provide their own > tab-completion, to make sure the same commandline-parser is used for > both completion and interpretation. I don't think the debate should be about how useful it is or how annoying it is. If I have a file called myfile.jpg how does *LINUX* know what the file is? You might think it's a picture because of the .jpg extension--but firefox will tell you based off the MIME TYPE. So will the file command. I'm not saying we need to integrate mime typing into tab completion--because it would probably slow things to a crawl, but since we can't do it the RIGHT way, we need another approach. Here's what I see--correct me if I'm wrong, or add to it: * Tab completion based off a file name or part of a file name is wrong. You don't know if myfile.jpg is really a jpg or a pdf or a text file. Take my original firefox example where myfile.asp was really a PDF. And just last night I tried to get mplayer to play a WMV file (windows media) and it wouldn't auto-complete. Although it played just fine. * Because restricted tab-completion is broken, we need to find a solution * A better way would be mime-type completion--but it would probably slow tab-completion to a crawl when you had more than a few files. (A quick non-scientific test in a src directory shows 17 files all less than 100K took 1.017 seconds) * Tracker seems pretty cool, but I know nothing about it. Can we query it for a file's mime type and make it fast? * Disable it or enable it by default but have an option to disable/enable it system wide and/or per-user. And just to be clear, I'm not talking about disabiling the ability to do something like "svn chec" to get "svn checkout" or tab-completion of ssh hostnames. I am specifically talking about limiting the list of files presented based on the application you are trying to start and the file extensions. What Ian said a few messages up the thread hits the nail on the head for me: "Predictability is far far more important than functionality for completion to be an effective useability aid." I think the best way to solve this is by using the last option above. Either enable or disable it by default, but provide options to enable/disable it on a per-user or per-system basis. It's not my right to tell someone they can't run their system using broken tab-completion if they want it that way. -A -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Restricted tab-completion is annoying
> I think this sucks. I spend a lot of time at the bash prompt and use > tab-completion constantly. When you are in bash, I would expect you sorta > know what you are doing. I totally forgot my other example until just a few minutes ago when I went to modify my apt sources list. sudo -e /etc/apt/sour gives me sudo -e /etc/apt/sources.list.d/ for no apparent reason. It doesn't appear to be a permissions issue. sudo vi /etc/apt/sour gives me the correct result--sudo vi /etc/apt/sources.list Perhaps this is something I should file a bug report on? -A -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Restricted tab-completion is annoying
> > If I modify them, doesn't that mean they will get overwritten by the next > > update to the bash package? > > not if you modify them in your own .bashrc Yeah--but system-wide I want it off. On the hosting server I own, I have 4 other admins that would absolutely hate this. > sniffing the mime type of every file in the directory each time you hit > ?? > The day it starts doing this I'll stop using it... Yeah--that's what I was saying. It seems like that would be a huge waste of resources. I guess I wasn't clear--but there are two paths. Do tab completion on a system I consider broken (based on file extension) which doesn't actually tell you what is in the file. Or what nautilus appears to be doing--displaying a 'type' column that ignores the file extension. I tested it with my PDF example. It's sorta a catch-22. Use the 'broken' system or use the bloated system that would require mime lookups on every file. In my opinion, both are bad. That's why I would love to disable is entirely and just have tab completion for every file. (And parameters to things like svn, rsync, etc...) > Do you have tracker or something similar installed ? > nautilus does NOT sniff the mime type when it shoes the content of a > directory, it does it only when you select the file I'm running a fairly default install of gutsy. Looking at the package list, it shows trackerd. Could bash maybe tie into that database easily? As much as I hate it restricting my tab-completion, at least it would be a little more accurate... Of course I may very well be a fringe case. > and I do not want it to show me the non-pdf files in the same directory. > I really like this filtering, but agree that we should have some way > to complete other files as well (by hitting tab again or > or whatever) Agreed. I would love to have a system-wide disable option and/or a per-account option. For now I'll settle for what Gavin said in his message to the list. Toss 'shopt -u progcomp' into your .bashrc Of course I'm not that familiar with bash, but I'm guessing that probably turns off my nice svn command completion too... ;) -A -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Restricted tab-completion is annoying
> you can of course modify tab-completion by > modifying /etc/bash_completion and the files in /etc/bash_completion.d > that might be what you want to do. If I modify them, doesn't that mean they will get overwritten by the next update to the bash package? > there are lots and lots of reasons to have program-specific > tab-completion. for instance, having acroread complete only .pdf files > means that the small number of pdf's in my home directory are easy to > find when i start acroread. I know the reasons for program-specific tab completion--I love it with svn, but it is annoying when you are trying to tab-complete a filename and it won't do it because the file doesn't end with PDF or pdf for example. To me it seems like this is heading down the windows route. Give all your file names a 3 character extension so you know what to open it with. Shouldn't it be more 'unixy' and be based on the mime-type of the file? I know that would be a major pain implementation-wise, because your tab-completion would then have to figure out the mime type for every file that matches, slowing things down a bit... This user-friendly restrictedness should be in the GUI. (I just checked, and gnome shows my file as a PDF no matter what extension it has.) I maintain that the bash prompt is not supposed to be a user-friendly environment. It's the bash prompt afterall. It's where admins, power-users, and all-around geeks can go to do advanced stuff. I don't think it's a good argument to say that people need to have user-friendly hand-holding at the command prompt. If I want to run 'evince somefile.asp' I should be able to. I don't care if the extension is .asp .pdf or .mystupidfile. Anyways--that's my .02, and thanks to Gavin and his message, I can always run 'shopt -u progcomp' in my .bashrc if everyone else thinks it's a good idea to keep it. -A -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Restricted tab-completion is annoying
Ok--I'm sorry, but none of what you said made any sense to me. > I don't see the point why filenames needs to be tab-completed on default, it > does it when it's necessary. I'm asking why tab-completion changed from allowing tab-completion of EVERY file to being restricted. It sounds like you are asking why it needs to be on at all. My response to that is that it is a feature that people like and use. It's been that way for as long as I can remember. At least 8 years. > Filenames does tab-complete on certain tasks and applications, depending on > what are you trying to accomplish? Is that a question or statement? Yes, you hit tab to complete certain commands and filenames. It seems like Ubuntu is trying to be helpful by showing you only the things it thinks you need. > For example, certain applications that require an input needs to > tab-complete a filename on it's parameters (i.e. rsync), and > executable files like python, perl, ruby & bash scripts would need > tab-completion to execute. Yes, that is why there is tab completion--because there are so many Linux command that take filenames as parameters. > If you really want to autocomplete your filenames, you might as well make > your files executable, So you are saying I should chmod +x all my videos, pictures, and music files in order to use tab-completion. That's an even worse solution. They aren't executable files. They are data files that need to be interpreted BY programs that I execute. > and lastly why do you think this is necessary? Why do I think what is necessary? Tab completion? Disabling the new restrictions to tab-completion? Being able to use a feature that has been in bash forever but was recently (in my opinion) crippled? -A -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Restricted tab-completion is annoying
Today a website generated a PDF file for me automatically and firefox popped up and asked if I wanted to download it. I hit 'OK' and it saved 'genpdf.asp' into my downloads folder. I was surprised to find bash wouldn't tab-complete the filename. Apparently there is new (newer than dapper) bash completion code that restricts completed files based on the initial part of the command. (/etc/bash_completion) I think this sucks. I spend a lot of time at the bash prompt and use tab-completion constantly. When you are in bash, I would expect you sorta know what you are doing. One example of where I *will* have issues is if I upgrade my home media server from Dapper to Gutsy. It stores all the video from my camcorder, copies of all my CDs and DVDs, pictures from digital cameras, etc... Most of the files don't have an extension because file extensions are sorta useless in Linux. If I upgrade to Gutsy it appears I won't be able to type in 'mplayer StarTrek-Wrath' and have it fill in 'StarTrek-Wrath_of_Kahn'. So I guess I have two questions * Why does the tab-completion code that restricts based on command-names exist? What benefit does this restriction have to power users?? * If it's here to stay, what is the official 'ubuntu way' to disable it for people who don't like it. It appears /etc/bash_completion is owned by the bash package. If I upgrade bash, will it come back? I want it off my servers and workstations perminantly. I see nothing in /etc/defaults. -A -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
