[Bug 978173] Re: $PATH not being honored
The problem has gone away after the ubuntu version I'm now running was installed. I think it's now 12-04 but I can't seem to get the machine to say that. uname -a shows this: Linux doug-GG045AA-ABA-a6142n 3.2.0-25-generic #40-Ubuntu SMP Wed May 23 20:30:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/978173 Title: $PATH not being honored To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/978173/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 978173] [NEW] $PATH not being honored
Public bug reported: Deimos ~/bin ls -l -rwxrwxr-x 1 doug doug 25 2012-04-10 10:10 firefox -rwx--x--x 1 doug doug 7236 2011-11-01 11:30 Firefox.pl -rwx--x--x 1 doug doug220 2011-11-01 11:30 Run_in_tcsh -rwx--x--x 1 doug doug 384456 2011-11-01 11:30 tcsh -rwx--x--x 1 doug doug 3197 2011-11-01 11:30 xorit A few have been snipped. Deimos ~/bin cat firefox /usr/bin/firefox -P default $1 Deimos ~/bin echo $PATH /home/doug/bin:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games Deimos ~/bin which firefox /usr/bin/firefox I want my personal versions to be executed when they come first in my path. They always used to but that was in real UNIX or before this version of ubuntu. /home/doug/bin/firefox works just the way I want it. Yes, I use tcsh but I get the same performance in bash. ProblemType: Bug DistroRelease: Ubuntu 11.10 Package: gnome-terminal 3.0.1-0ubuntu3 ProcVersionSignature: Ubuntu 3.0.0-18.31-generic 3.0.26 Uname: Linux 3.0.0-18-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 1.23-0ubuntu4 Architecture: amd64 Date: Tue Apr 10 10:22:30 2012 ExecutablePath: /usr/bin/gnome-terminal InstallationMedia: Ubuntu 11.10 Oneiric Ocelot - Release amd64 (20111012) SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: gnome-terminal (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug apport-lpi oneiric running-unity -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/978173 Title: $PATH not being honored To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/978173/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 978173] Re: $PATH not being honored
-- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/978173 Title: $PATH not being honored To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/978173/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 474579] Re: No backup files created in home directory
I no longer have the problem but. . . It's definitely related to access control lists. There seems to be no way to turn off access control. setfacl -b fileref # doesn't work as advertised. I believe that to be well known. A solution is to remove whole directories of files and re-create them. Unless you deliberately set an ACL they will stay as created. It is likely that my home directory was once infected with ACL rules during an unsuccessful attempt to use SELinux. As far as gedit is concerned the bug should remain closed. But then as a suggested improvement it would be nice if gedit recognized an inability to save a ~ file because of ACL's and report it that way. -- No backup files created in home directory https://bugs.launchpad.net/bugs/474579 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 474556] Re: Tools in 2.28.0 now must start with a shebang #! line.
Jesse van den Kieboom jesse...@gnome.org has privately advised me that the bugs have been fixed in the next version of gedit. -- Tools in 2.28.0 now must start with a shebang #! line. https://bugs.launchpad.net/bugs/474556 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 474579] Re: No backup files created in home directory
I have a fix. I no longer think it's a problem with gedit or gnome. Some time ago I experimented with SELinux and soon decided I didn't want to use it. The two users around here are both trustworthy and I didn't see an advantage when port 23 for ssh is the only real exposure to the internet. We thought we removed SELinux using the GUI to reinstall and restart. It appears that process didn't do everything. We still had access control lists for a lot of directories including all of the $HOME variety. Gedit was being denied directory access to create *~ files and it's procedure apparently needs to create a new one before it overwrites the old - that's reasonable. The fix was to commit a couple of day's effort to learn about ACLs (access control lists) and how to get rid of them. setfacl and getfacl are two tools delivered with ubuntu with man pages are one place to start. setfacl -x u:doug doug with the working directory set to /home/doug/ made it possible for gedit to make backups in my directory. setfattr is not delivered with ubuntu but can be obtained using Synaptic. After considerable trial and error: sudo setfattr -h -x security.selinux * ;# fixes every subdirectory in the current directory. The way that everything has to be done with root access can only mean that SELinux has more to do with careless users than it has to do with internet attacks. ACLs are apparently part of the Linux kernel and SELinux just uses them. This bug, and probably #251083, can be considered closed. Well, I with gedit working as user doug I still don't understand why ACLs prevented creation of *~ files in doug's home directory. Perhaps something to do with setuid? -- No backup files created in home directory https://bugs.launchpad.net/bugs/474579 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 474556] Re: Tools in 2.28.0 now must start with a shebang #! line.
** Attachment added: Dependencies.txt http://launchpadlibrarian.net/35109853/Dependencies.txt ** Attachment added: ProcMaps.txt http://launchpadlibrarian.net/35109855/ProcMaps.txt ** Attachment added: ProcStatus.txt http://launchpadlibrarian.net/35109856/ProcStatus.txt ** Attachment added: XsessionErrors.txt http://launchpadlibrarian.net/35109860/XsessionErrors.txt -- Tools in 2.28.0 now must start with a shebang #! line. https://bugs.launchpad.net/bugs/474556 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gedit in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 474556] [NEW] Tools in 2.28.0 now must start with a shebang #! line.
Public bug reported: Binary package hint: gedit Tools in 2.28.0 now must start with a shebang #! line at least in Ubuntu 9.10 The shebang line must point to a shell. But... #!/usr/bin/perl seems to be an exception to that. There is no longer a procedure to simply pass files that don't start with #! to a default shell. That's understandable but it needs to be right up front as a significant change. Somewhere a #! line needs to get converted to an execve kernel call. Is gedit doing it? Or is gedit passing the task off to a shell? If so is gedit passing arguments in the #! line? If I try to put a call to, say, curl in the #! line the arguments are not handled well. In transfering control to tcsh my .tcshrc is getting called as a remote login which triggers a login message of my creation. That shouldn't be happening when gedit opens a new shell. Gedit seems to be setting environment variable $REMOTEHOST which is tested by my .tcshrc file. Bash shows essentially the same characteristics. ProblemType: Bug Architecture: amd64 Date: Wed Nov 4 11:11:12 2009 DistroRelease: Ubuntu 9.10 ExecutablePath: /usr/bin/gedit NonfreeKernelModules: nvidia Package: gedit 2.28.0-0ubuntu2 ProcEnviron: PATH=(custom, user) LANGUAGE=en_US.UTF-8 SHELL=/bin/tcsh LANG=en_US.UTF-8 ProcVersionSignature: Ubuntu 2.6.31-14.48-generic SourcePackage: gedit Uname: Linux 2.6.31-14-generic x86_64 ** Affects: gedit (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug -- Tools in 2.28.0 now must start with a shebang #! line. https://bugs.launchpad.net/bugs/474556 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gedit in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 474566] [NEW] Problem displaying underline in file name for a tool
Public bug reported: Binary package hint: gedit The external tools selection window has a problem with underline characters in file names. My tool Finance_Get shows up as FinanceGet with the letter G underlined. There is also a FinanceGet file in /tools/ but there is no confusion. In the manage external tools window the underline shows up properly. This appears to be a display only problem that doesn't affect performance. ** Affects: gedit (Ubuntu) Importance: Undecided Status: New -- Problem displaying underline in file name for a tool https://bugs.launchpad.net/bugs/474566 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gedit in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 474579] [NEW] No backup files created in home directory
Public bug reported: Binary package hint: gedit Possibly related to Bug #251083 gedit still refuses to make a backup file when the original is at the top level of a user's home directory. Any file being edited with gedit which is of the form /home/user/somename will result in a message that informs of the inability to save a backup - with a ~ at the end - when the first save is requested after opening the file. Hidden files - .tcshrc for instance - make a workaround impossible because they must remain in $HOME/ ** Affects: gedit (Ubuntu) Importance: Undecided Status: New -- No backup files created in home directory https://bugs.launchpad.net/bugs/474579 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gedit in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 474595] [NEW] Tools no longer direct stderr into the bottom pane.
Public bug reported: Binary package hint: gedit Shell tools and scripts used to modify the content of a file being edited often generate progress output delivered in stderr. That material is rarely, if ever, intended to become a part of the file being edited. It really should go to the bottom pane as it did before 2.28. As a sample: Contents of Finance_Get in .gnome2/gedit/tools #!/home/doug/bin/tcsh # [Gedit Tool] # Comment=Read finance snippet into selection # Name=Finance_Get # Languages=plain # Applicability=all # Output=insert # Input=nothing # Save-files=nothing /usr/bin/curl http://macnauchtan.com/cgi-bin/suntide.cgi Result: Hello , welcome to Mars. ;# This is from my .tcshrc file which tests for $REMOTEHOST, perhaps another bug. % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 5030 5030 0 2324 0 --:--:-- --:--:-- --:--:-- 4412 !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN HTML BODY pSuntideIP: 174.22.131.171/p prsa_pub: B3NzaC1yc2EBIwAAAQEA2tp96NTIma SNIP /BODY /HTML The output to stderr is mixed with stdout by gedit. The return characters used by curl and the backspacing foul up the text output in stdout. It's really intended for display in a terminal. ** Affects: gedit (Ubuntu) Importance: Undecided Status: New -- Tools no longer direct stderr into the bottom pane. https://bugs.launchpad.net/bugs/474595 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gedit in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 95519] Re: Nautilus-scripts don't handle blanks in filenames properly
Content of $HOME/.gnome2/nautilus-scripts/expose #!/bin/tcsh set report = $HOME/expose.txt echo $report date $report echo Arg1 is $1 $report echo Arg2 is $2 $report echo Arg3 is $3 $report echo NAUTILUS_SCRIPT_SELECTED_FILE_PATHS $report echo $NAUTILUS_SCRIPT_SELECTED_FILE_PATHS $report echo NAUTILUS_SCRIPT_SELECTED_URIS $report echo $NAUTILUS_SCRIPT_SELECTED_URIS $report echo NAUTILUS_SCRIPT_WINDOW_GEOMETRY $report echo $NAUTILUS_SCRIPT_WINDOW_GEOMETRY $report echo NAUTILUS_SCRIPT_CURRENT_URI $report echo $NAUTILUS_SCRIPT_CURRENT_URI -- $report I have selected three files in my home directory space\ space space2\ \ space2 ScratchPad This is the result of choosing scripts_expose with the right mouse button: Sat May 3 19:56:56 MDT 2008 Arg1 is ScratchPad Arg2 is space2 space2 Arg3 is space space NAUTILUS_SCRIPT_SELECTED_FILE_PATHS /home/doug/ScratchPad /home/doug/space2 space2 /home/doug/space space NAUTILUS_SCRIPT_SELECTED_URIS file:///home/doug/ScratchPad file:///home/doug/space2%20%20space2 file:///home/doug/space%20space NAUTILUS_SCRIPT_WINDOW_GEOMETRY 847x753+767+72 NAUTILUS_SCRIPT_CURRENT_URI Note that the arguments are correct. Note that the selected URI's properly show the URL-encoded double space in the file name. Note that the file paths have truncated the double space into a single space. The only document I have is Ubuntu Hacks, O'Reilly, June 2006 which clearly says the files and URIs are new-line delimited in Hack 24. It appears that the current rule is to use a double space. -- Nautilus-scripts don't handle blanks in filenames properly https://bugs.launchpad.net/bugs/95519 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
