finding executable files in a debian package
Is this the best way? dpkg -L python-docutils | xargs ls -dF | grep \* I used to do dpkg -L python-docutils | grep bin but it seems this doesn't catch them all. Also, should all executable files be in bin/ directories according to the Debian packaging guidelines or the filesystem hierarchy standard? I couldn't find an answer to that with a quick look.
Hi Andrew, On 2013-06-04 19:12, Andrew Spiers wrote:
Is this the best way?
dpkg -L python-docutils | xargs ls -dF | grep \*
Certainly not! parsing ls is almost *always* the wrong answer http://mywiki.wooledge.org/ParsingLs
I used to do
dpkg -L python-docutils | grep bin
Yeah, also not reliable, because some executables may be library-type binaries that are separate binaries but not expected to be called in isolation. These would likely go in *lib/. As an example: mattcen@owen:tmp$ dpkg -L mutt | while read -r file; do test -f "$file" && test -x "$file" && echo "$file"; done /usr/bin/smime_keys /usr/bin/mutt-org /usr/bin/mutt_dotlock /usr/lib/mutt/mailto-mutt /usr/lib/mutt/pgpring /usr/lib/mutt/mailspell /usr/lib/mutt/debian-ldap-query /usr/lib/mutt/pgpewrap /usr/lib/mutt/source-muttrc.d /usr/share/bug/mutt/script Note the above command: This is how I'd find executable files in a package. Note echos files that are (a) a file (as opposed to a directory, link, etc.), and (b) are executable by the current user. See 'help test' for more information.
but it seems this doesn't catch them all.
Also, should all executable files be in bin/ directories according to the Debian packaging guidelines or the filesystem hierarchy standard?
See above. Further, example scripts may live in /usr/share, and these may be executable too.
I couldn't find an answer to that with a quick look.
-- Regards, Matthew Cengia
On 2013-06-04 19:33, Matthew Cengia wrote: [...]
mattcen@owen:tmp$ dpkg -L mutt | while read -r file; do test -f "$file" && test -x "$file" && echo "$file"; done [...] Note the above command: This is how I'd find executable files in a package. Note echos files that are (a) a file (as opposed to a directory, link, etc.), and (b) are executable by the current user. See 'help test' for more information.
Also note that this assumes (reasonably, in this case, in my opinion) that no filenames contain newlines. dpkg doesn't seem to have an option to output filenames delimited with null characters rather than newlines, and I also am unaware of a way to express this in the package file when creating a package. Nonetheless, if you had output that was null-delimited, that could be parsed by changing the while loop to: while IFS= read -rd ''; do See http://mywiki.wooledge.org/BashFAQ/020 for more info. -- Regards, Matthew Cengia
Andrew Spiers <andrew@andrewspiers.net> wrote:
Is this the best way?
dpkg -L python-docutils | xargs ls -dF | grep \*
Perhaps a variant of this? for fn in $(dpkg -L python-docutils) ; do [ -f $fn -a -x $fn ] && echo $fn ; done You could use the officially deprecated but ubiquitous `...` syntax rather than $(...) if you prefer. Note that the -f test is needed to exclude directories.
On 2013-06-04 19:37, Jason White wrote:
Andrew Spiers <andrew@andrewspiers.net> wrote:
Is this the best way?
dpkg -L python-docutils | xargs ls -dF | grep \*
Perhaps a variant of this? for fn in $(dpkg -L python-docutils) ; do [ -f $fn -a -x $fn ] && echo $fn ; done
You could use the officially deprecated but ubiquitous `...` syntax rather than $(...) if you prefer.
Note that the -f test is needed to exclude directories.
Hi Jason, That's a slightly different approach, and one that I don't think does as much quoting as it should. If you can reasonably make assumptions about (for example) the absense of spaces in filenames of deb packages, then your approach will work, but mine is slightly more robust. I'd have quoted every expansion of "$fn", and not used the $() because of the space issue. The while loop (with data passed in via a pipe or fd) is more robust here, but as mentioned, given the limitations of dpkg -L, doesn't handle filenames containing newlines. -- Regards, Matthew Cengia
Matthew Cengia <mattcen@gmail.com> wrote:
That's a slightly different approach, and one that I don't think does as much quoting as it should. If you can reasonably make assumptions about (for example) the absense of spaces in filenames of deb packages, then your approach will work, but mine is slightly more robust. I'd have quoted every expansion of "$fn", and not used the $() because of the space issue.
Agree on both points, although I'm yet to find a file name containing spaces on my machine.
On Tue, Jun 4, 2013 at 7:55 PM, Jason White <jason@jasonjgw.net> wrote:
Agree on both points, although I'm yet to find a file name containing spaces on my machine.
A few on mine: http://packages.debian.org/wheezy/amd64/kde-telepathy-text-ui/filelist http://packages.debian.org/wheezy/all/kipi-plugins-common/filelist http://packages.debian.org/wheezy/all/xbmc/filelist for instance, / Brett
On Tue, Jun 04, 2013 at 08:52:42PM +1000, Brett Pemberton wrote:
Agree on both points, although I'm yet to find a file name containing spaces on my machine.
A few on mine:
http://packages.debian.org/wheezy/amd64/kde-telepathy-text-ui/filelist http://packages.debian.org/wheezy/all/kipi-plugins-common/filelist http://packages.debian.org/wheezy/all/xbmc/filelist
OK, i really must add "-d '\n'" to numerous invocations of xargs in dlocate. even when i wrote it fifteen years ago i should have used 'tr' to convert newlines into NULs and used 'xargs -0'...it's what i normally did anyway before xargs acquired a '-d' option. craig -- craig sanders <cas@taz.net.au> BOFH excuse #291: Due to the CDA, we no longer have a root account.
On 2013-06-04 21:40, Craig Sanders wrote:
On Tue, Jun 04, 2013 at 08:52:42PM +1000, Brett Pemberton wrote:
Agree on both points, although I'm yet to find a file name containing spaces on my machine.
A few on mine:
http://packages.debian.org/wheezy/amd64/kde-telepathy-text-ui/filelist http://packages.debian.org/wheezy/all/kipi-plugins-common/filelist http://packages.debian.org/wheezy/all/xbmc/filelist
OK, i really must add "-d '\n'" to numerous invocations of xargs in dlocate.
even when i wrote it fifteen years ago i should have used 'tr' to convert newlines into NULs and used 'xargs -0'...it's what i normally did anyway before xargs acquired a '-d' option.
Using tr to convert newlines to \0 for parsing with xargs -0 is no better than using xargs without -0. How does tr know whether a newline is part of the filename, or a delimiter between filenames? Only the program generating the file list could know that. -- Regards, Matthew Cengia
On Tue, Jun 04, 2013 at 10:45:38PM +1000, Matthew Cengia wrote:
Using tr to convert newlines to \0 for parsing with xargs -0 is no better than using xargs without -0. How does tr know whether a newline is part of the filename, or a delimiter between filenames? Only the program generating the file list could know that.
tr doesn't and can't. it's still a LOT better (than xargs' default of white-space as a delimter) because even though \n is a valid character in a filename, only the most pathologically stupid people or broken software or the most unlikely of contrived cases would actually use one. you just shouldn't do some things even though it's technically permitted. it's also no different to using -d '\n' with a modern xargs. in both cases, you're making the assumption that only an idiot would use a newline in a filename so it's safe to rely on it as a filename delimiter. some assumptions are reasonable to make. spaces in filenames, OTOH, are quite common. especially if you have to deal with files uploaded by Mac or Windows users. using -d '\n' or converting newlines to NULs for use with -0 are both conviently useful in such cases...with the proviso, of course, that you understand that pathologically stupid and unlikely filenames with newlines in them can still be a problem. in the case of debian package listings, the format IS newline separated, with one filename per line - an extremely common format on *nix systems for filenames and many other text lists. craig -- craig sanders <cas@taz.net.au> BOFH excuse #289: Interference between the keyboard and the chair.
On 2013-06-04 23:45, Craig Sanders wrote:
On Tue, Jun 04, 2013 at 10:45:38PM +1000, Matthew Cengia wrote:
Using tr to convert newlines to \0 for parsing with xargs -0 is no better than using xargs without -0. How does tr know whether a newline is part of the filename, or a delimiter between filenames? Only the program generating the file list could know that.
tr doesn't and can't.
it's still a LOT better (than xargs' default of white-space as a delimter) because even though \n is a valid character in a filename, [...]
My apologies, for some bizarre reason I assumed that xargs defaulted to newline-delimited rather than whitespace-delimited. In this case you're right; explicitly forcing newline delimiting using any method is less bad. -- Regards, Matthew Cengia
On Wed, 5 Jun 2013, Matthew Cengia wrote:
On 2013-06-04 23:45, Craig Sanders wrote:
it's still a LOT better (than xargs' default of white-space as a delimter) because even though \n is a valid character in a filename, [...]
My apologies, for some bizarre reason I assumed that xargs defaulted to newline-delimited rather than whitespace-delimited. In this case you're right; explicitly forcing newline delimiting using any method is less bad.
It is an awful pain though. I can count the number of times I've wanted xargs to split on spaces rather than newline, on my naked singularity (maybe it's a good thing in that it forces you to think before applying). Put it up there with historical stupidities like crontab(5) being minute hour ... -- Tim Connors
On 04.06.13 23:45, Craig Sanders wrote:
spaces in filenames, OTOH, are quite common. especially if you have to deal with files uploaded by Mac or Windows users.
Although it's mostly xpdf which won't handle spaces in filenames, I'm finding a simple alias useful for the few arriving here: alias unspace="/usr/bin/rename 's/ /_/g' " Filename completion fortunately handles spaces, so: $ touch /tmp/"another spaced filename" $ unspace /tmp/another\ spaced\ filename $ ls /tmp/an* /tmp/another_spaced_filename doesn't require much typing, after the first line. Oh for the halcyon days when we could just tell users that spaces weren't allowed. Erik -- Life is complex: it has a real part and an imaginary part. - Martin Terma
Erik Christiansen <dvalin@internode.on.net> wrote:
On 04.06.13 23:45, Craig Sanders wrote:
spaces in filenames, OTOH, are quite common. especially if you have to deal with files uploaded by Mac or Windows users.
I don't have to deal with those, fortunately. Anything that arrives in e-mail attachments gets renamed anyway in most cases to make it easier to find later.
Although it's mostly xpdf which won't handle spaces in filenames, I'm finding a simple alias useful for the few arriving here:
alias unspace="/usr/bin/rename 's/ /_/g' "
That's useful, thanks. I'll save it for when the problem arises.
Oh for the halcyon days when we could just tell users that spaces weren't allowed.
Agreed. On my machines, though, I'm the only user and I'm not responsible for other peoples' systems, so it's easy to enforce that kind of requirement here.
On Wed, 5 Jun 2013, Erik Christiansen wrote:
On 04.06.13 23:45, Craig Sanders wrote:
spaces in filenames, OTOH, are quite common. especially if you have to deal with files uploaded by Mac or Windows users.
Although it's mostly xpdf which won't handle spaces in filenames,
Eh? WFM.
I'm finding a simple alias useful for the few arriving here:
alias unspace="/usr/bin/rename 's/ /_/g' "
Isn't it easier just to fix your scripts (and evidentally your alias for xpdf) and program defensively? -- Tim Connors
On 06.06.13 10:19, Tim Connors wrote:
On Wed, 5 Jun 2013, Erik Christiansen wrote:
On 04.06.13 23:45, Craig Sanders wrote:
spaces in filenames, OTOH, are quite common. especially if you have to deal with files uploaded by Mac or Windows users.
Although it's mostly xpdf which won't handle spaces in filenames,
Eh? WFM.
Ah, you're having trouble understanding it. That's OK, just learn from what follows, and you'll catch up.
I'm finding a simple alias useful for the few arriving here:
alias unspace="/usr/bin/rename 's/ /_/g' "
Isn't it easier just to fix your scripts (and evidentally your alias for xpdf) and program defensively?
Hopefully it'll be easier for you to understand if you fantasise less, and instead observe reality: $ cp Desktop/h-bridge_sch_pcb.pdf /tmp/h-bridge\ sch\ pcb.pdf $ /usr/bin/xpdf /tmp/h-bridge\ sch\ pcb.pdf Error: Couldn't open file '/tmp/h-bridge sch pcb.pdf' Just in case there's been a recent fix, I did an apt-get install, but there's no improvement in the behaviour of the package. I see now, that some time ago I implemented this fix: $ which xpdf xpdf is a function xpdf () { if [[ $1 =~ ' ' ]]; then fn=${1// /_}; mv "$1" $fn; else fn=$1; fi; /usr/bin/xpdf -geometry 1200x900+5+0 -z width -papercolor slategrey $fn & } so the rename example I posted as part of a wider discussion isn't needed here for this case. Hopefully you understand better now. Erik P.S. It appears that /usr/bin/xpdf, provided by the xpdf package, is in fact a wrapper, so I could merge my function with that, but then it would be overwritten on the next upgrade. Maybe I'll download the version 3.03 source from foolabs one day, to see what it offers, but it'll soon be time to upgrade my ubuntu LTS version, so it's better to suffer all the pain in one annoying session. -- The only thing to do with good advice is pass it on. It is never any use to oneself. - Oscar Wilde
On 6 June 2013 18:56, Erik Christiansen <dvalin@internode.on.net> wrote:
$ cp Desktop/h-bridge_sch_pcb.pdf /tmp/h-bridge\ sch\ pcb.pdf $ /usr/bin/xpdf /tmp/h-bridge\ sch\ pcb.pdf Error: Couldn't open file '/tmp/h-bridge sch pcb.pdf'
Just in case there's been a recent fix, I did an apt-get install, but there's no improvement in the behaviour of the package.
Seems to work fine for me on Debian wheezy. -- Brian May <brian@microcomaustralia.com.au>
On 06.06.13 19:05, Brian May wrote:
On 6 June 2013 18:56, Erik Christiansen <dvalin@internode.on.net> wrote:
$ cp Desktop/h-bridge_sch_pcb.pdf /tmp/h-bridge\ sch\ pcb.pdf $ /usr/bin/xpdf /tmp/h-bridge\ sch\ pcb.pdf Error: Couldn't open file '/tmp/h-bridge sch pcb.pdf'
Just in case there's been a recent fix, I did an apt-get install, but there's no improvement in the behaviour of the package.
Seems to work fine for me on Debian wheezy.
Thanks, I might go back to Debian on the desktop machine, now that I've replaced the motherboard which wouldn't take Debian, years ago. (The laptop is already Debian + LXDE.) The ubuntu installer autodetects the partition with the most current OS, and proposes the older for the install. I might have to pay much closer attention during a Debian install. (I always keep the previous install, as a fallback, when taking the new one on board.) Erik -- For humans, honesty is a matter of degree. Engineers are always honest in matters of technology and human relationships. That's why it's a good idea to keep engineers away from customers, romantic interests, and other people who can't handle the truth. (Scott Adams - The Dilbert principle)
On 06/06/13 19:46, Erik Christiansen wrote:
Just in case there's been a recent fix, I did an apt-get install, but there's no improvement in the behaviour of the package.
This space issue is an bug in the xpdf wrapper script that was fixed upstream about mid 2011. It works fine in Debian 7.0 stable and should be okay in the current Ubuntu 12.04 LTS unless there has been a regression. Glenn -- sks-keyservers.net 0x6d656d65
On Thu, Jun 06, 2013 at 07:46:54PM +1000, Erik Christiansen wrote:
The ubuntu installer autodetects the partition with the most current OS, and proposes the older for the install. I might have to pay much closer attention during a Debian install.
why reinstall? seems to me as if that's missing most of the point of both debian and ubuntu. 'apt-get dist-upgrade' works better than re-installing - doesn't lose your existing configuration or require significant downtime (a few minutes to reboot to start using the updated kernel). or on ubuntu, there's a wrapper script called 'do-release-upgrade'. not really sure what, if any, benefit it has over 'apt-get dist-upgrade' but it's there all the same. automatically updates the sources.list to the latest alliterated animal at least, and probably other stuff.
(I always keep the previous install, as a fallback, when taking the new one on board.)
in my experience, you're much better off fixing the occasional minor problems or incompatibilities after an upgrade than you are trying to revert back to an earlier version. plus, you get exciting new bugs to discover rather than boring old ones. craig -- craig sanders <cas@taz.net.au>
Craig Sanders <cas@taz.net.au> writes:
or on ubuntu, there's a wrapper script called 'do-release-upgrade'. not really sure what, if any, benefit it has over 'apt-get dist-upgrade' but it's there all the same. automatically updates the sources.list to the latest alliterated animal at least, and probably other stuff.
Debian has release notes. For example, anyone doing a simple "dist-upgrade" from Squeeze to Wheezy is likely to completely bugger their system due to apt blowing its heap trying to find an ordering ("could not perform immediate configuration"). Anyone that follows the release notes FIRST can allegedly avoid this, but once it's happened repairing it is allegedly hard. Ubuntu knows their users can't read, so instead they use d-r-u, which basically downlaods a tarball of filthy little kludges to workaround upgrade issues. I'm extremely unenthusiastic about the latter approach because I believe it ends up being used to try to auto-detect things that it can't get 100% right, so unusual systems explode on upgrade. I also believe this negatively impacts the quantity and quality of upgrade notes. OTOH, it has been pointed out that d-r-u's approach would have allowed the DDs to avoid the immediate-configuration issue entirely, because d-r-u's tarball exists outside the repo, so what it downloads is the current version, rather than what existed as at squeeze. Overall, I think it's reasonable to use a d-r-u approach in moderation, for things that you can reliably detect and fix, AND can't be fixed fix in-band with NMUs. Things that might require human judgement in edge cases should continue to be documented in the release notes.
On 07.06.13 13:20, Trent W. Buck wrote:
For example, anyone doing a simple "dist-upgrade" from Squeeze to Wheezy is likely to completely bugger their system due to apt blowing its heap trying to find an ordering ("could not perform immediate configuration").
Ah, then dist-upgrade remains an unreliable process, even on debain. I'd clone before upgrading, for quick unbuggering, but a process which doesn't work is of limited usefulness. At least, on redhat, ISTR that an attempted upgrade overreach resulted in a safe failure to proceed, and a warning. Finding an old intermediate version, and upgrading in two steps worked. (Many years ago. Haven't tried since.)
Anyone that follows the release notes FIRST can allegedly avoid this, but once it's happened repairing it is allegedly hard.
A dist-upgrade upgrades thousands of files, across hundreds of packages. I'm at a loss to understand how it could be either practical or worthwhile to manually check for stuff-ups across all of them. I'm accustomed to scouring README and INSTALL notes on source tarballs, but a working package manager is constructed for the purpose of managing the installs, at least to the extent of not doing harm. (It can't always be expected to succeed in installing, I accept.)
Ubuntu knows their users can't read, so instead they use d-r-u, which basically downloads a tarball of filthy little kludges to workaround upgrade issues.
That seems like a definitive recommendation for installing, and not upgrading. Erik -- Never worry about theory as long as the machinery does what it's supposed to do. - Robert A. Heinlein
Erik Christiansen <dvalin@internode.on.net> writes:
On 07.06.13 13:20, Trent W. Buck wrote:
For example, anyone doing a simple "dist-upgrade" from Squeeze to Wheezy is likely to completely bugger their system due to apt blowing its heap trying to find an ordering ("could not perform immediate configuration").
Ah, then dist-upgrade remains an unreliable process, even on debain. I'd clone before upgrading, for quick unbuggering, but a process which doesn't work is of limited usefulness.
FWIW, Craig's suggestion of doing upgrades a little bit at a time (on testing/unstable) would fix this -- the problem arises AIUI because there is SO MUCH that has changed between 6 and 7, that apt gives up before it finds an optimal install order.
A dist-upgrade upgrades thousands of files, across hundreds of packages. I'm at a loss to understand how it could be either practical or worthwhile to manually check for stuff-ups across all of them.
Debian releases on average every two years. Whinging about having to be a bit careful once every two years seems a bit picayune.
On 07.06.13 12:13, Craig Sanders wrote:
On Thu, Jun 06, 2013 at 07:46:54PM +1000, Erik Christiansen wrote:
The ubuntu installer autodetects the partition with the most current OS, and proposes the older for the install. I might have to pay much closer attention during a Debian install.
why reinstall? seems to me as if that's missing most of the point of both debian and ubuntu.
'apt-get dist-upgrade' works better than re-installing - doesn't lose your existing configuration or require significant downtime (a few minutes to reboot to start using the updated kernel).
Yes, having to reinstall all the extra bits and pieces is a major part of the pain every three years, so dist-upgrade sounds attractive, if it is reliable now. But ISTR that it probably won't jump me from e.g. Ubuntu 10.04.1 LTS to the new LTS. Things like having to blow away NetworkManager, to get networking to work, on each ubuntu installation, are also small irritations. If a dist-upgrade would respect its omission, then I could try an annual dist-upgrade. Switch back to debian, then try dist-upgrade every year or so, seems a good way forward, given your advice. ...
in my experience, you're much better off fixing the occasional minor problems or incompatibilities after an upgrade than you are trying to revert back to an earlier version.
When I buy a car, it should not require repairs in the first three years. There's so much else to spend time on, that unproductive distro futzing does not appeal any more.
plus, you get exciting new bugs to discover rather than boring old ones.
Hmmm, is it three decades spent fixing bugs in my own software which causes the entertainment value of bugs to be a much devalued currency here? I'm not admitting to getting slower, just more easily frustrated when time is taken from the tasks at hand. I'll give it a go. It can't all break on a minor upgrade. Erik -- Leibowitz's Rule: When hammering a nail, you will never hit your finger if you hold the hammer with both hands.
On Fri, Jun 07, 2013 at 06:37:21PM +1000, Erik Christiansen wrote:
Yes, having to reinstall all the extra bits and pieces is a major part of the pain every three years, so dist-upgrade sounds attractive, if it is reliable now. But ISTR that it probably won't jump me from e.g. Ubuntu 10.04.1 LTS to the new LTS.
IMO using Ubuntu LTS is worse than using debian stable. by the time there's a new release they're not even recognisably the same OS - whatever was the great future direction in one LTS release will probably have been forgotten and replaced with something newer and shinier several times over by the next LTS. debian stable, for example, will offer upstart and systemd as options you can choose if you want, but it won't force them on you. default settings and default packages change only if there's an exceptionally good reason for it. chasing after current fads is generally not considered sufficient reason.
Things like having to blow away NetworkManager, to get networking to work, on each ubuntu installation, are also small irritations. If a dist-upgrade would respect its omission, then I could try an annual dist-upgrade.
dunno about ubuntu, but on debian i purged NetworkManager and similar dreck years ago (pretty much as soon as it appeared). it has never re-appeared on any subsequent upgrade - dozens of systems, hundreds of upgrades.
Switch back to debian, then try dist-upgrade every year or so, seems a good way forward, given your advice.
it wasn't so much advice as a question, i wanted to know if there was a good reason for your upgrade method. my method works for me and has done since i started using debian in 1994, and i've always seen in-place upgradability as one of debian's major advantages over (initially) SLS and Slackware and later Redhat and other upstart newcomers. it may work for you too, or it may not. my preference is to run debian sid aka 'unstable', even on most production servers (with very few exceptions - and even there i prefer 'testing' to 'stable'). but then, I think that the version of the distro is pretty much irrelevant, what matters is the versions of the packages installed. i.e. i don't really give a damn if i'm running debian 6.0 squeeze or 7.0 wheezy - but i do care what version of apache or postfix or mysql or postgres or whatever i have installed on any given machine. To me, installing the latest debian 'stable' release is just the first step in getting the REAL debian - sid, or testing - onto a machine. stable with some cherry-picking from testing or sid may work better for you. my suggestion would be that 'stable' is OK for 6 months or so after it is released but starting to get a bit stale. by twelve months, 'testing' is definitely better.
in my experience, you're much better off fixing the occasional minor problems or incompatibilities after an upgrade than you are trying to revert back to an earlier version.
When I buy a car, it should not require repairs in the first three years. There's so much else to spend time on, that unproductive distro futzing does not appeal any more.
software isn't a car, and neither is a computer. car-based analogies, popular as they are, don't really make sense. but if you insist on a car analogy....when you upgrade the radio in your car to the latest model, sometimes the controls are identical or very similar to the previous model, and sometimes they're completely different and require some practice before you get used to them. so it is with software upgrades and config files, usually they're the same but sometimes there are incompatible differences between the new version and the old. and the more that gets upgraded at once, the more problems there will be. i.e. a steady series of small incremental upgrades is far less troublesome than one huge upgrade every year or three.
plus, you get exciting new bugs to discover rather than boring old ones.
Hmmm, is it three decades spent fixing bugs in my own software which causes the entertainment value of bugs to be a much devalued currency
maybe i should have put a smiley on the end of that sentence. craig -- craig sanders <cas@taz.net.au> BOFH excuse #355: Boredom in the Kernel.
Craig Sanders <cas@taz.net.au> writes:
stable with some cherry-picking from testing or sid may work better for you.
The regulars of #debian *emphatically* discourage cherry-picking from stable to testing. Mixing testing/unstable is always du jour.
software isn't a car, and neither is a computer. car-based analogies, popular as they are, don't really make sense.
OTOH new cars have lots of computers in them, and the people building them don't seem to have had a lot of practice at security :-P
Erik Christiansen <dvalin@internode.on.net> writes:
Yes, having to reinstall all the extra bits and pieces is a major part of the pain every three years, so dist-upgrade sounds attractive, if it is reliable now. But ISTR that it probably won't jump me from e.g. Ubuntu 10.04.1 LTS to the new LTS.
Ubuntu explicitly claims to support this. My experiences with 8.04 -> 10.04 were dismal compared to my experiences with Debian dist-upgrades; on most hosts I did, d-r-u crashed halfway through and left me to clean up the inconsistent state. (I'm afraid I don't remember the details.) Note that LTS->LTS is only supported when the .1 of the target release comes out. Also note (as always) that "5-years support" is supplied on a per-package basis, to a strict subset of their already marginal "main" section. Ref. the "supported" field in apt (not found in Debian). Also, since I'm on the subject, I'd like to alert people who haven't read the Wheezy release notes, that Debian won't commit to providing suppot for GUI browsers except for chromium and iceweasel.
On Thu, 6 Jun 2013, Erik Christiansen wrote:
On 06.06.13 10:19, Tim Connors wrote:
On Wed, 5 Jun 2013, Erik Christiansen wrote:
On 04.06.13 23:45, Craig Sanders wrote:
spaces in filenames, OTOH, are quite common. especially if you have to deal with files uploaded by Mac or Windows users.
Although it's mostly xpdf which won't handle spaces in filenames,
Eh? WFM.
Ah, you're having trouble understanding it. That's OK, just learn from what follows, and you'll catch up.
I'm finding a simple alias useful for the few arriving here:
alias unspace="/usr/bin/rename 's/ /_/g' "
Isn't it easier just to fix your scripts (and evidentally your alias for xpdf) and program defensively?
Hopefully it'll be easier for you to understand if you fantasise less, and instead observe reality:
$ cp Desktop/h-bridge_sch_pcb.pdf /tmp/h-bridge\ sch\ pcb.pdf $ /usr/bin/xpdf /tmp/h-bridge\ sch\ pcb.pdf Error: Couldn't open file '/tmp/h-bridge sch pcb.pdf'
Ah, I see, you're using an inferior OS. Might want to submit a bug to get them to pull the fixes that have been in upstream Debian for years now. Like I said, WFM:
xpdf -m flex\ hours.pdf flex\ hours.pdf echo $? #wheee! 0
Just in case there's been a recent fix, I did an apt-get install, but there's no improvement in the behaviour of the package.
I see now, that some time ago I implemented this fix:
$ which xpdf xpdf is a function xpdf () { if [[ $1 =~ ' ' ]]; then fn=${1// /_}; mv "$1" $fn; else fn=$1; fi; /usr/bin/xpdf -geometry 1200x900+5+0 -z width -papercolor slategrey $fn & }
so the rename example I posted as part of a wider discussion isn't needed here for this case.
Hopefully you understand better now.
Not really. In that case, I would have submitted a bug. Not handling shell script escaping properly is the mark of … something that leaves a bad mark. To have such bugs creep into an OS is just shitty. They're usually RC bugs in debian, because there's no excuse for such dangerous programming. -- Tim Connors
Erik Christiansen <dvalin@internode.on.net> writes:
alias unspace="/usr/bin/rename 's/ /_/g' "
Suggest '[[:space:]]' instead of just ' '.
Filename completion fortunately handles spaces, so:
$ touch /tmp/"another spaced filename" $ unspace /tmp/another\ spaced\ filename
You might as well just "unspace *"; it'll noop normal stuff and be idempotent on the problem ones.
Trent W. Buck <trentbuck@gmail.com> wrote:
You might as well just "unspace *"; it'll noop normal stuff and be idempotent on the problem ones.
Agreed. The manual page indicates that rename(1) won't overwrite existing files accidentally, in as much as overwriting requires use of the -f option, so it should be safe. When using mv on a large number of files, I usually specify mv -i just to make sure.
Jason White <jason@jasonjgw.net> writes:
You could use the officially deprecated but ubiquitous `...` syntax rather than $(...) if you prefer.
Citation needed. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag... ...doesn't mention deprecation (at least, I can't spot it). I agree it's a bloody stupid thing to do, when $() has been around for so long. greybot> The backquote (`) is used in the old-style command greybot> substitution, e.g. foo=`command`. The foo=$(command) syntax is greybot> recommended instead. Backslash handling inside $() is less greybot> surprising, and $() is easier to nest. See greybot> http://mywiki.wooledge.org/BashFAQ/082
Trent W. Buck <trentbuck@gmail.com> wrote:
Jason White <jason@jasonjgw.net> writes:
You could use the officially deprecated but ubiquitous `...` syntax rather than $(...) if you prefer.
Citation needed.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag...
...doesn't mention deprecation (at least, I can't spot it). I agree it's a bloody stupid thing to do, when $() has been around for so long.
I think it was in a bash announcement or changelog quite a while back. If so, it would mean deprecated in bash, not in POSIX.
On Wed, Jun 5, 2013 at 12:18 PM, Jason White <jason@jasonjgw.net> wrote:
I think it was in a bash announcement or changelog quite a while back. If so, it would mean deprecated in bash, not in POSIX.
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
Isn't Debian generally averse to bashisms in scripts anyway? Probably why I was unaware of it. Also Craig, thanks for dlocate, I use it a lot! -- Unattributed this email sig is. -- Darth Vader
Hi everyone, thanks for all the responses. I'm combining my replies to everyone into one message. Matthew: .. yeah I kinda new parsing ls was bad. I'd originally tried to do this piping dpkg -L to find, but couldn't seem to come up with a method of doing that that work Find is probably also the wrong tool for the job. Jason: Good suggestion, using [ is clearly the right tool for testing if something is executable or not. Trent:
Why do you want to find "all executables" ? I knew there was something to convert rst to html on my system, I figured it would be in docutils, but I had no idea what it was called.
Craig: Thanks for putting dlocate into debian, if I can remember its name I'll use it next time I want to do this.
Andrew Spiers <andrew@andrewspiers.net> writes:
Is this the best way? dpkg -L python-docutils | xargs ls -dF | grep \*
Yuk.
I used to do dpkg -L python-docutils | grep bin but it seems this doesn't catch them all.
grep bin/ ought to find the ones you actually care about -- the ones for end users. Why do you want to find "all executables" ?
Also, should all executable files be in bin/ directories according to the Debian packaging guidelines or the filesystem hierarchy standard?
No, there are things like /usr/lib/frobozz/libexec and /usr/lib/cgi-bin.
On Tue, Jun 04, 2013 at 07:12:38PM +1000, Andrew Spiers wrote:
Is this the best way?
dpkg -L python-docutils | xargs ls -dF | grep \*
I used to do
dpkg -L python-docutils | grep bin
# apt-get install dlocate # dlocate -lsbin python-docutils /usr/share/docutils/scripts/python2/rst2html /usr/share/docutils/scripts/python2/rst2latex /usr/share/docutils/scripts/python2/rst2man /usr/share/docutils/scripts/python2/rst2odt /usr/share/docutils/scripts/python2/rst2odt_prepstyles /usr/share/docutils/scripts/python2/rst2pseudoxml /usr/share/docutils/scripts/python2/rst2s5 /usr/share/docutils/scripts/python2/rst2xetex /usr/share/docutils/scripts/python2/rst2xml /usr/share/docutils/scripts/python2/rst-buildhtml /usr/share/docutils/scripts/python2/rstpep2html note that 'dpkg -L python-docutils | grep bin' wouldn't have found any of the above executables, because they're not in a directory named bin/ disclaimer: dlocate is my package. worse, the '-lsbin' option parses the output of ls. it does, however, work because it's reasonably safe to assume GNU ls on debian systems (and it really only prints out the filenames of normal - non-directory/link/socket/device-node etc - files when there's an 'x' or 's' in the perms field of 'ls -lLd', anyway, which is predictable and standard). it is also a lot faster than, e.g., running a for-loop around stat. the shell code in dlocate that implements -lsbin looks like this: '-lsbin') if [ -s $DPKG_INFO/$PKG.list ] ; then dlocate -L $PKG | \ xargs -r ls -lLd 2> /dev/null | \ grep -v "^[^-]" | \ grep -E '^-.{2,8}[xs]' | \ sed -e 's/.* \//\//' | \ xargs -r ls -1 result=$? else echo Package $PKG not installed or $PKG.list is empty. >&2 result=1 fi ;; i wrote that around fifteen years ago, and haven't looked at it since....but looking at it now, i can see a number of ways to improve it. starting with (even though i haven't yet run into any packages with spaces in the filenames) adding "-d '\n'" to both invocations of xargs so that it uses \n as the delimeter rather than any whitespace. xargs didn't have a '-d' option fifteen years ago. and the 'grep | grep | sed' could be replaced with just a single call to sed (at the cost of the script's readability). the first grep is redundant, and the second grep can be merged into the sed script: dlocate -L "$PKG" | \ xargs -d '\n' -r ls -lLd 2> /dev/null | \ sed -n -r -e '/^-.{2,8}[xs]/ s/.* \//\//p' | \ xargs -d '\n' -r ls -1 FYI, 'dlocate -L $PKG' just cats /var/lib/dpkg/info/$PKG.list - 'dpkg -L' works as well. so there's a /usr/local/sbin/lsbin script for you if you don't want to install dlocate. dlocate does a lot more than just lsbin, though: $ dlocate -h Usage: dlocate [option...] [command] [PATTERN...] Commands: DEFAULT/none PATTERN list records that match either package or files names -S PATTERN list records that match filenames -L package list all files in package -l package regexp-enhanced emulation of 'dpkg -l' -s package print package's status -ls package 'ls -ldF' of all files in package -du package 'du -sck' of all files in package -conf package list conffiles in package -lsconf package 'ls -ldF' of conffiles in package -md5sum package list package's md5sums (if any) -md5check package check package's md5sums (if any) -man package list package's man pages (if any) -lsman package list full path/filenames of man pages -lsbin package list full path/filenames of executable files -K list installed kernel & related packages -k detailed list of installed kernel & related packages The -l, and -S commands are approximately the same as the equivalent dpkg options except that the search is performed using regular expressions rather than fixed strings. Options --filename-only only output file names when searching for files --package-only only output package names when searching for files Regular Expression Options (see grep(1) for details): -E, --extended-regexp -F, --fixed-strings -G, --basic-regexp -P, --perl-regexp -w, --word-regexp restrict matches to whole words -i, --ignore-case case-insensitive match Miscellaneous Options: -h, -H, --help display this help message and exit. -V, --version display dlocate's version number and exit. -v, --verbose, --debug verbose/debug output craig -- craig sanders <cas@taz.net.au>
participants (12)
-
Andrew Spiers -
Brett Pemberton -
Brian May -
Craig Sanders -
Erik Christiansen -
ewe2 -
Glenn McIntosh -
Jason White -
Jeremy Visser -
Matthew Cengia -
Tim Connors -
trentbuck＠gmail.com