Re: units issues
On 2017-05-24 20:07, Doug Henderson wrote:
> , On 24 May 2017 at 18:16, Brian Inglis wrote:
>> I would appreciate it if anyone has any experience with, or can point me
>> to, any python3 code in any Cygwin package which works Windows proxy
>> authentication?
> I had a glance at the source. I recall adapting it to load SQL tables
> with units data. I recall writing code very similar to that in the
> units_cur{2|3} python sources to keep the table current.
> units_cur2 is the python2 version, units_cur3 is the python3 version
> of the updater.
> It is using the urllib and ElementTree packages which are parts of the
> standard python release.
> A possibly more featureful replacement for urllib is the requests
> package, available in the cygwin packages python2-requests and
> python3-requests. See http://docs.python-requests.org/en/master/ for
> the documentation. It claims "HTTP(S) Proxy Support" however I have
> not used that feature.
> There are two similar lines that use urllib:
> ... urllib.request.urlopen('URL1>') ...
> ... urllib.request.urlopen('?f=xml') ...
> Using requests, they become:
> ... requests.get('').text ...
> ... requests.get('', params={'f':'xml'}).text ...
> Some additional code is required to support proxies, but I can't help
> much there.
> See http://docs.python-requests.org/en/master/user/advanced/#proxies for info.
Hi Doug,
Thanks for the pointers which document things better than urllib.
It looks like it should be possible to support proxies by setting
environment variables:
{HTTP,HTTPS}_PROXY={http,https,socks5}://user:password@host:port/
I will check this out further to see whether that requires urllib2,
urllib3, or requests, which are packaged for cygwin, and follow up with
the OP on the issue, to see what works.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Re: units issues
, On 24 May 2017 at 18:16, Brian Inglis wrote:
> I would appreciate it if anyone has any experience with, or can point me
> to, any python3 code in any Cygwin package which works Windows proxy
> authentication?
I had a glance at the source. I recall adapting it to load SQL tables
with units data. I recall writing code very similar to that in the
units_cur{2|3} python sources to keep the table current.
units_cur2 is the python2 version, units_cur3 is the python3 version
of the updater.
It is using the urllib and ElementTree packages which are parts of the
standard python release.
A possibly more featureful replacement for urllib is the requests
package, available in the cygwin packages python2-requests and
python3-requests. See http://docs.python-requests.org/en/master/ for
the documentation. It claims "HTTP(S) Proxy Support" however I have
not used that feature.
There are two similar lines that use urllib:
... urllib.request.urlopen('URL1>') ...
... urllib.request.urlopen('?f=xml') ...
Using requests, they become:
... requests.get('').text ...
... requests.get('', params={'f':'xml'}).text ...
Some additional code is required to support proxies, but I can't help
much there.
See http://docs.python-requests.org/en/master/user/advanced/#proxies for info.
HTH
Doug
--
Doug Henderson, Calgary, Alberta, Canada - from gmail.com
Re: units issues
On 2017-05-24 12:13, Achim Gratz wrote: > Brian Inglis writes: >> Updating the currencies only when setup is run seems to me to be >> insufficient if users want to use current currency conversions. > > Well yes. But that means that each user should be able to update, not > just the administrator. > >> Would the best approach be to punt on running the update script at all, >> install a null /usr/share/units/currency.units file, announce and >> document that if currency conversions are desirable, the user should >> arrange to run the update script, either from the command line, profile, >> cron job, or Task Scheduler? > > In that case the file should not be packaged at all and it should live > in /usr/var somewplace, I think. But if you think a bit further you'll > see that this wouldn't be sufficient when the user cannot write there. > >> If we kept the postinstall script, we could change it to run only if the >> currency.units file is non-null and drop the time check: >> [ -s /usr/share/units/currency.units ] && /usr/bin/units_cur >> or keep the time check, using find -mtime +0, or date and stat. > > Again, if you package that updater, it'd make sense to create a > sub-package just for that and provide any customization as to which > update style is preferred (the things you mentioned are all sensible in > some situation, just not together). The longer I think about it the > less convincing the idea that a postinstalll script should do the actual > updating, although it might be one of the options you offer. The updater is part of the installed package. Running it in postinstall was added by the original cygwin packager. I am now leaning heavily towards a /usr/share/doc/Cygwin/units.README documenting the commands to automate currency updates properly, the possible approaches to implementing the commands, leaving the mechanism to the user to implement, and conspicuously referring to that doc in future upgrade notices. I will try again to contact upstream via bug-un...@gnu.org this time, and work on fixing the issues with the updater site cert expiry, by retrying with cert checking disabled, and see if I can come up with another fix to work with Windows proxy authentication. I would appreciate it if anyone has any experience with, or can point me to, any python3 code in any Cygwin package which works Windows proxy authentication? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Re: units issues
Brian Inglis writes: > Updating the currencies only when setup is run seems to me to be > insufficient if users want to use current currency conversions. Well yes. But that means that each user should be able to update, not just the administrator. > Would the best approach be to punt on running the update script at all, > install a null /usr/share/units/currency.units file, announce and > document that if currency conversions are desirable, the user should > arrange to run the update script, either from the command line, profile, > cron job, or Task Scheduler? In that case the file should not be packaged at all and it should live in /usr/var somewplace, I think. But if you think a bit further you'll see that this wouldn't be sufficient when the user cannot write there. > If we kept the postinstall script, we could change it to run only if the > currency.units file is non-null and drop the time check: > [ -s /usr/share/units/currency.units ] && /usr/bin/units_cur > or keep the time check, using find -mtime +0, or date and stat. Again, if you package that updater, it'd make sense to create a sub-package just for that and provide any customization as to which update style is preferred (the things you mentioned are all sensible in some situation, just not together). The longer I think about it the less convincing the idea that a postinstalll script should do the actual updating, although it might be one of the options you offer. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: units issues
Buchbinder, Barry (NIH/NIAID) [E] writes: > I would prefer that by default updates happen automatically and those > who do not want automatic updates do something to stop them from > happening. That there should be updates was never debated, only the machanism of doing so is discussed here. > For instance, someone who does not want updates makes the > definitions file read-only and have the script check for write > permission and exit or skip updating if the file cannot be written. A > zero length read-only file works if one is worried about someone using > stale conversion factors. An environmental variable whose existence > marks no-update might be another possibility. No again. In general, it is a no-no to alter or remove files that came with the package (besides, the user might not even be able to, depending on how Cygwin gets installed). Cygwin isn't very fussy about such errors at the moment, but that shouldn't be an excuse to become sloppy. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: units issues
On 2017-05-24 10:26, Buchbinder, Barry (NIH/NIAID) [E] wrote: > Brian Inglis sent the following at Tuesday, May 23, 2017 10:37 PM >> On 2017-05-23 17:55, Doug Henderson wrote: >>> On 23 May 2017 at 15:49, Brian Inglis wrote: Updating the currencies only when setup is run seems to me to be insufficient if users want to use current currency conversions. >> It's a command line utility from GNU with currency conversion factors >> in a separate definition file included from the main file, updated by >> a Python script, which downloads an RSS XML file of current (Euro) >> rates from a free source with a permissive licence, and converts it to >> definitions acceptable to the utility, overwriting the existing file. >> >> The main issues are that, as currently implemented, currency rates are >> updated automatically by a postinstall script only when setup is run; >> setup may be running in an environment without external access, so the >> postinstall script will generate an error; users may not want or care >> about currency updates; and the postinstall script uses find to avoid >> updating if there is no currency file, or it has been updated recently. >> >> One option to deal with this is update the package to install a >> zero length currency definitions file, so currency conversions are >> not defined, but the program has no issues, and drop the permanent >> postinstall script to perform updates. Then announce and document that >> users who want updated currency conversion rates need to run the update >> script from the command line, a profile script, cron job, or Windows >> Scheduled Task, as is desirable if they use currency conversions. > I would prefer that by default updates happen automatically and those > who do not want automatic updates do something to stop them from > happening. For instance, someone who does not want updates makes the > definitions file read-only and have the script check for write > permission and exit or skip updating if the file cannot be written. A > zero length read-only file works if one is worried about someone using > stale conversion factors. An environmental variable whose existence > marks no-update might be another possibility. I agree with Achim that currency updates should not be done at postinstall, as the user could be doing an automated install with no external access, and we don't know that. With no guaranteed automatic execution facility, we don't even have a mechanism, how should updates should be done automatically and how can we provide this? Alternative suggestions for automated updates are welcome and why I am asking here. For other services, we leave it to users to figure out how to start them up and shut them down before setup is run. We could install an /etc/profile.d script which asks the user first time thru if they want daily currency updates during login over the network, and then either null or update currencies, and after do or do not update currencies. We could document how updates could be run: run the command from the shell, or add the necessary code to: some profile or profile.d script; command alias or function wrapper in some profile script; script which uses units currencies, cron job, or Windows Scheduled Task. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
RE: units issues
Brian Inglis sent the following at Tuesday, May 23, 2017 10:37 PM > >On 2017-05-23 17:55, Doug Henderson wrote: > >> On 23 May 2017 at 15:49, Brian Inglis wrote: >> >>> Updating the currencies only when setup is run seems to me to be >>> insufficient if users want to use current currency conversions. >> >> Currencies needs to be split to a different package from non-currency >> units. Non-currency units is very static, whereas most currencies >> changes daily. In the absence of updates, non-currency units are still >> useful; but currencies are incorrect in most cases, and increasingly >> so as time pass. >> >> It is difficult to predict user requirements based on current package >> dependencies as non-currency units and currencies are likely used by >> almost disjoint sets of packages. Users of non-currency units should >> not be burdened by the complexities of currencies. But if they do need >> currencies, they should be up to date. >> >> A possible solution is to check the currency of the currency data on >> library initialization or each use by comparing the current date with >> the data's date of update. When the data is stale, automatically >> update it if possible, or notify the user of the problem. > >It's a command line utility from GNU with currency conversion factors >in a separate definition file included from the main file, updated by >a Python script, which downloads an RSS XML file of current (Euro) >rates from a free source with a permissive licence, and converts it to >definitions acceptable to the utility, overwriting the existing file. > >The main issues are that, as currently implemented, currency rates are >updated automatically by a postinstall script only when setup is run; >setup may be running in an environment without external access, so the >postinstall script will generate an error; users may not want or care >about currency updates; and the postinstall script uses find to avoid >updating if there is no currency file, or it has been updated recently. > >One option to deal with this is update the package to install a >zero length currency definitions file, so currency conversions are >not defined, but the program has no issues, and drop the permanent >postinstall script to perform updates. Then announce and document that >users who want updated currency conversion rates need to run the update >script from the command line, a profile script, cron job, or Windows >Scheduled Task, as is desirable if they use currency conversions. > >There are also issues with the Python update script, as the currency >source site cert expired recently, causing the update and postinstall >scripts to fail, with no workaround other than a replacement or patch; >and a poster has problems using the update script with Windows proxies, >which I have addressed to the upstream maintainer for discussion about >approaches. If there is no response, I will create a Cygwin update patch >and submit it upstream, but there has been no visible response to issues >raised on the GNU site. I would prefer that by default updates happen automatically and those who do not want automatic updates do something to stop them from happening. For instance, someone who does not want updates makes the definitions file read-only and have the script check for write permission and exit or skip updating if the file cannot be written. A zero length read-only file works if one is worried about someone using stale conversion factors. An environmental variable whose existence marks no-update might be another possibility. Best wishes, - Barry Disclaimer: Statements made herein are not made on behalf of NIAID.
Re: units issues
On 2017-05-23 17:55, Doug Henderson wrote: > On 23 May 2017 at 15:49, Brian Inglis wrote: > >> Updating the currencies only when setup is run seems to me to be >> insufficient if users want to use current currency conversions. > > Currencies needs to be split to a different package from non-currency > units. Non-currency units is very static, whereas most currencies > changes daily. In the absence of updates, non-currency units are still > useful; but currencies are incorrect in most cases, and increasingly > so as time pass. > > It is difficult to predict user requirements based on current package > dependencies as non-currency units and currencies are likely used by > almost disjoint sets of packages. Users of non-currency units should > not be burdened by the complexities of currencies. But if they do need > currencies, they should be up to date. > > A possible solution is to check the currency of the currency data on > library initialization or each use by comparing the current date with > the data's date of update. When the data is stale, automatically > update it if possible, or notify the user of the problem. It's a command line utility from GNU with currency conversion factors in a separate definition file included from the main file, updated by a Python script, which downloads an RSS XML file of current (Euro) rates from a free source with a permissive licence, and converts it to definitions acceptable to the utility, overwriting the existing file. The main issues are that, as currently implemented, currency rates are updated automatically by a postinstall script only when setup is run; setup may be running in an environment without external access, so the postinstall script will generate an error; users may not want or care about currency updates; and the postinstall script uses find to avoid updating if there is no currency file, or it has been updated recently. One option to deal with this is update the package to install a zero length currency definitions file, so currency conversions are not defined, but the program has no issues, and drop the permanent postinstall script to perform updates. Then announce and document that users who want updated currency conversion rates need to run the update script from the command line, a profile script, cron job, or Windows Scheduled Task, as is desirable if they use currency conversions. There are also issues with the Python update script, as the currency source site cert expired recently, causing the update and postinstall scripts to fail, with no workaround other than a replacement or patch; and a poster has problems using the update script with Windows proxies, which I have addressed to the upstream maintainer for discussion about approaches. If there is no response, I will create a Cygwin update patch and submit it upstream, but there has been no visible response to issues raised on the GNU site. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Re: units issues
On 23 May 2017 at 15:49, Brian Inglis wrote: > Updating the currencies only when setup is run seems to me to be > insufficient if users want to use current currency conversions. Currencies needs to be split to a different package from non-currency units. Non-currency units is very static, whereas most currencies changes daily. In the absence of updates, non-currency units are still useful; but currencies are incorrect in most cases, and increasingly so as time pass. It is difficult to predict user requirements based on current package dependencies as non-currency units and currencies are likely used by almost disjoint sets of packages. Users of non-currency units should not be burdened by the complexities of currencies. But if they do need currencies, they should be up to date. A possible solution is to check the currency of the currency data on library initialization or each use by comparing the current date with the data's date of update. When the data is stale, automatically update it if possible, or notify the user of the problem. Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com
Re: units issues
On 2017-05-23 11:28, Achim Gratz wrote: > Brian Inglis writes: >> The easiest approaches to this would be: >> - rename or delete postinstall script which might upset cygcheck or >> setup remove >> - null /usr/share/units/currency.units, as it is required and produces >> an error message if not available, but if it is empty, everything works. > > Nope. The user should not have to muck with packaged files at all. > >> It is not very useful if not up to date (I run the update daily), and if >> not up to date, might as well be empty, but some opinions may differ. > > The issue is that you cannot assume that postinstall scripts are able to > access the network at all. Where this isn't possible the administrator > will have to find a different way of keeping those files up-to-date > (which should also not be packaged), but that's something to maybe just > document. But you will have to provide some way of letting the user > specify if that updating is OK. If you want this to be possible during > the initial install you might even need to provide another sub-package > whose only purpose is to confer this decision (it could be empty and > just doing a simple postinstall action). > >> In the postinstall script find which ensures updates happen at most daily: > > I've asked specifically to structure any perpetual postinstall script in > a way that it doesn't do any non-necessary work, be it forking or > otherwise unless it is going to actually do something useful. A simple > file test that exits the postinstall script when the file is or isn't > there satisfies that constraint, running commands and scripts doesn't. Updating the currencies only when setup is run seems to me to be insufficient if users want to use current currency conversions. Would the best approach be to punt on running the update script at all, install a null /usr/share/units/currency.units file, announce and document that if currency conversions are desirable, the user should arrange to run the update script, either from the command line, profile, cron job, or Task Scheduler? If we kept the postinstall script, we could change it to run only if the currency.units file is non-null and drop the time check: [ -s /usr/share/units/currency.units ] && /usr/bin/units_cur or keep the time check, using find -mtime +0, or date and stat. I have followed up with the upstream maintainer AdrianM at GNU dot org about the Python currency update script issues with no response yet. Does anyone have contact or know a better address to try? PM if so. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Re: units issues
Brian Inglis writes: > The easiest approaches to this would be: > - rename or delete postinstall script which might upset cygcheck or > setup remove > - null /usr/share/units/currency.units, as it is required and produces > an error message if not available, but if it is empty, everything works. Nope. The user should not have to muck with packaged files at all. > It is not very useful if not up to date (I run the update daily), and if > not up to date, might as well be empty, but some opinions may differ. The issue is that you cannot assume that postinstall scripts are able to access the network at all. Where this isn't possible the administrator will have to find a different way of keeping those files up-to-date (which should also not be packaged), but that's something to maybe just document. But you will have to provide some way of letting the user specify if that updating is OK. If you want this to be possible during the initial install you might even need to provide another sub-package whose only purpose is to confer this decision (it could be empty and just doing a simple postinstall action). > In the postinstall script find which ensures updates happen at most daily: I've asked specifically to structure any perpetual postinstall script in a way that it doesn't do any non-necessary work, be it forking or otherwise unless it is going to actually do something useful. A simple file test that exits the postinstall script when the file is or isn't there satisfies that constraint, running commands and scripts doesn't. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: units issues
On the cygwin list, Achim Gratz asked: > Can you please make that configurable by some file in /var/lib/units > that will prevent the perpetual postinstall script from even forking > if the user decides that this should not be updated? Configuration of units is currently supported only in /usr/share/units/*.units files which are defaulted by the utility, specified on the command line, included from one of those, or specified in ~/.units, and conditions may be specified depending only on either locale or an environment variable. The easiest approaches to this would be: - rename or delete postinstall script which might upset cygcheck or setup remove - null /usr/share/units/currency.units, as it is required and produces an error message if not available, but if it is empty, everything works. It is not very useful if not up to date (I run the update daily), and if not up to date, might as well be empty, but some opinions may differ. In the postinstall script find which ensures updates happen at most daily: /usr/bin/find /usr/share/units/currency.units -mtime +0 -exec /usr/bin/units_cur \; I could add a -size +0 qualifier, which would skip the update if the file is empty, and avoid creating a config flag file in directory /var/lib/units/, which is not currently created or used by the package. I will ask upstream about disabling currency updates by the python script, as that would be a preferred configurable approach. In any case, I will raise handling an expired cert in the python update script upstream, and suggest a configurable override. Please respond with any advice on how disabling pi updates and expired certs are or should be dealt with in postinstall scripts or python (I posted a temporary replacement workaround script and change to the original on the cygwin list, so the technical workaround is known and handled). and Ian Lambert reported: > In /var/log/setup.log.full I see: > Error connecting to currency server. not known> > Running /usr/bin/units_cur or /etc/postinstall/zp_units_cur.sh I get > Error connecting to currency server. HTTP Error 407: Proxy Authentication > Required > I'm behind a proxy requiring username, password, and restrictions on > user-agents... I will raise handling proxies upstream, but once again, any advice is welcome, including technical approaches that work with Windows proxies under Cygwin in python3 (I am not a "python guy", and resort to google and SO, although some of those "suggestions" just don't work, as I found looking for ways to handle the expired cert). I posted responses that I'd take the issues upstream, follow up here, and report back, or provide a package update. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Re: Units
Last time I simply removed the `test' marker. This time I'll ask. John, are you sure that it should become a `test' version? Please see setup.html. It explicitly requires this for new packages. Rob
Re: Units
Ok, I bit. Step 5: 5. Create setup.hint file following the documentation on this web page. For new packages the first upload MUST be tagged as experimental. Once the package has no major bug reports from the users, then a current package may be introduced Rob
Re: Units
On Thu, Dec 20, 2001 at 08:53:30PM +1100, Robert Collins wrote: Ok, I bit. Step 5: 5. Create setup.hint file following the documentation on this web page. For new packages the first upload MUST be tagged as experimental. Once the package has no major bug reports from the users, then a current package may be introduced I hate that. Quote from a few lines above the `setup.hint' section: Test versions are specified via the setup.hint file as described below. It is not required that your package have a test version. Use of a test version of a package is at the discretion of the package maintainer. And how long does it take to wait for major bug reports from the users? 1 day? A week? A month? Not amused, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
RE: bash completion (was: RE: Units)
I found a problem with the bash_completion as stands... I have a path ~/Applications/Apache Group/ with no other directory in Applications starting with 'A'. When I cd ~/Applications/A[tab] it doesn't autocomplete. When I look through the shell script I can see... snippit # Turn on extended globbing and programmable completion shopt -s extglob progcomp # A lot of the following one-liners were taken directly from the # completion examples provided with the bash 2.04 source distribution # Make directory commands see only directories complete -d cd mkdir rmdir pushd /snippit removing 'cd' from the complete -d doesn't fix this. I'm CC'ing the original author (Ian Caliban). If cygwin folks want to take it and take a look I still recommend doing so (all the other things I've tried work very nicely), as for putting it in the distro I'd prefer to find out if this is expected behaviour or not. Sorry to have caused so much hassle just to retract it :( J. === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
Re: bash completion (was: RE: Units)
=== - Original Message - From: Morrison, John [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, December 20, 2001 10:02 PM Subject: RE: bash completion (was: RE: Units) I found a problem with the bash_completion as stands... ... Sorry to have caused so much hassle just to retract it :( I wouldn't worry - this is the whole point of having new packages start out as 'experimental'. It allows some breathing room. Rob
Re: bash completion (was: RE: Units)
On Thu, Dec 20, 2001 at 11:02:07AM -, Morrison, John wrote: I found a problem with the bash_completion as stands... I have a path ~/Applications/Apache Group/ with no other directory in Applications starting with 'A'. When I cd ~/Applications/A[tab] it doesn't autocomplete. That's actually weird. I'm using default completion in bash and I don't see a problem with `cd /cygdrive/c/DocTAB'. It completes correctly to `cd /cygdrive/c/Documents\ and\ Settings/'. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
RE: bash completion (was: RE: Units)
-Original Message- From: Corinna Vinschen [mailto:[EMAIL PROTECTED]] Sent: Thursday, 20 December 2001 11:22 am To: '[EMAIL PROTECTED]' Subject: Re: bash completion (was: RE: Units) On Thu, Dec 20, 2001 at 11:02:07AM -, Morrison, John wrote: I found a problem with the bash_completion as stands... I have a path ~/Applications/Apache Group/ with no other directory in Applications starting with 'A'. When I cd ~/Applications/A[tab] it doesn't autocomplete. That's actually weird. I'm using default completion in bash and I don't see a problem with `cd /cygdrive/c/DocTAB'. It completes correctly to `cd /cygdrive/c/Documents\ and\ Settings/'. Yeah - that's what I used to get too - so I'm assuming it's something to do with this file... J. === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
Re: Units
On Thu, Dec 13, 2001 at 03:40:35PM -, Morrison, John wrote: Hi, I've packaged up the latest version of units. I've just uploaded it to sourceware. You might consider to send a message to [EMAIL PROTECTED] in a few hours. Please keep the format as you will find it in the cygwin-announce mailing list archive. The announcement will automatically be propagated to the cygwin mailing list as soon as it has been approved so you don't need to send a second announcement to the base list. Thanks for the new package, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
RE: Units
Thanks. Will do. btw, since you prob a *lot* more about bash than I do (since you're the maintainer for cygwin ;) have you any idea's why that's scripts messing cd's auto completion up? J. -Original Message- From: Corinna Vinschen [mailto:[EMAIL PROTECTED]] Sent: Thursday, 20 December 2001 11:29 am To: Morrison, John Cc: '[EMAIL PROTECTED]' Subject: Re: Units On Thu, Dec 13, 2001 at 03:40:35PM -, Morrison, John wrote: Hi, I've packaged up the latest version of units. I've just uploaded it to sourceware. You might consider to send a message to [EMAIL PROTECTED] in a few hours. Please keep the format as you will find it in the cygwin-announce mailing list archive. The announcement will automatically be propagated to the cygwin mailing list as soon as it has been approved so you don't need to send a second announcement to the base list. Thanks for the new package, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:[EMAIL PROTECTED] Red Hat, Inc. === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
Re: bash completion (was: RE: Units)
=== - Original Message - From: Morrison, John [EMAIL PROTECTED] To: 'Robert Collins' [EMAIL PROTECTED]; Morrison, John [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, December 20, 2001 10:50 PM Subject: RE: bash completion (was: RE: Units) Question: does experimental == test? If it does then we shouldn't refer to things as experimental but as being 'in test'. If not then should the test: line in setup.hint be changed to experimental: ? I know it's more typing but... True. Rob
Re: Units
Corinna Vinschen wrote: On Thu, Dec 20, 2001 at 08:53:30PM +1100, Robert Collins wrote: Ok, I bit. Step 5: 5. Create setup.hint file following the documentation on this web page. For new packages the first upload MUST be tagged as experimental. Once the package has no major bug reports from the users, then a current package may be introduced I hate that. Quote from a few lines above the `setup.hint' section: Test versions are specified via the setup.hint file as described below. It is not required that your package have a test version. Use of a test version of a package is at the discretion of the package maintainer. And how long does it take to wait for major bug reports from the users? 1 day? A week? A month? Not amused, Corinna Nor, am I amused. If it must be tagged I'd rather see the tag NEW instead, unless the maintainer believes that it's actually an experimental version. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: Units
On Thu, Dec 20, 2001 at 11:39:13AM -, Morrison, John wrote: Thanks. Will do. btw, since you prob a *lot* more about bash than I do (since you're the maintainer for cygwin ;) have you any idea's why that's scripts messing cd's auto completion up? Prepared for disappointment? Ok, then, here we go: I'm using tcsh all the time, except I have to test something in or with bash. I'm not a bash expert, I'm justy maintaining it because somebody has to do it(tm). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
RE: Units
Oh well - never mind :) I CC'd the original author, hopefully either he (or somebody on this list...? :) can fix it *GRIN*. J. -Original Message- From: Corinna Vinschen [mailto:[EMAIL PROTECTED]] Sent: Thursday, 20 December 2001 12:45 pm To: '[EMAIL PROTECTED]' Subject: Re: Units On Thu, Dec 20, 2001 at 11:39:13AM -, Morrison, John wrote: Thanks. Will do. btw, since you prob a *lot* more about bash than I do (since you're the maintainer for cygwin ;) have you any idea's why that's scripts messing cd's auto completion up? Prepared for disappointment? Ok, then, here we go: I'm using tcsh all the time, except I have to test something in or with bash. I'm not a bash expert, I'm justy maintaining it because somebody has to do it(tm). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:[EMAIL PROTECTED] Red Hat, Inc. === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
Re: Units
On Thu, Dec 20, 2001 at 02:09:17PM -0500, Christopher Faylor wrote: On Thu, Dec 20, 2001 at 07:38:39AM -0500, Earnie Boyd wrote: Corinna Vinschen wrote: Not amused, Corinna Nor, am I amused. If it must be tagged I'd rather see the tag NEW instead, unless the maintainer believes that it's actually an experimental version. I think I've already given my opinion on this, too. I don't see any reason for a new package to be marked Test. What's the gain? It will just result in the package getting almost no exposure. What extra information will be gained by making it Test? Will the new user be more forgiving? More apt to report bugs? I don't get it. I thought the intent of Test was to have a version of a product for people to try while still providing a safety net of a stable version to fall back to. I don't see how that applies to the first release of a new package. So back to the original question: John, are you sure that it should become a `test' version? Otherwise I'll remove it. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: bash completion (was: RE: Units)
Charles Wilson wrote: John, why don't you create a bashutils package, to serve as a collection of (moderately) useful bash scripts and settings. For now, it could contain only bashcompletion, but later you could add -- oh, bashprompt, or something... I'm sure every daily bash user has interesting things to contribute. Myself, I have a bunch of aliases I depend on daily, and install on every machine I get an account on. -- = ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m
RE: Units
Hi, I think this reply is too late (since I've just downloaded it from a mirror ;), I don't mind whether it's a test version or not - but the docs are still not terribly clear wrt this (IMHO). I'll send an announcement tomorrow. Thanks, J. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Corinna Vinschen Sent: Thursday, 20 December 2001 7:26 pm To: [EMAIL PROTECTED] Subject: Re: Units On Thu, Dec 20, 2001 at 02:09:17PM -0500, Christopher Faylor wrote: On Thu, Dec 20, 2001 at 07:38:39AM -0500, Earnie Boyd wrote: Corinna Vinschen wrote: Not amused, Corinna Nor, am I amused. If it must be tagged I'd rather see the tag NEW instead, unless the maintainer believes that it's actually an experimental version. I think I've already given my opinion on this, too. I don't see any reason for a new package to be marked Test. What's the gain? It will just result in the package getting almost no exposure. What extra information will be gained by making it Test? Will the new user be more forgiving? More apt to report bugs? I don't get it. I thought the intent of Test was to have a version of a product for people to try while still providing a safety net of a stable version to fall back to. I don't see how that applies to the first release of a new package. So back to the original question: John, are you sure that it should become a `test' version? Otherwise I'll remove it. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: Units
- Original Message - From: Christopher Faylor [EMAIL PROTECTED] I don't see how that applies to the first release of a new package. I'd call it pretty basic risk management. If the package doesn't cause any havoc, then put it in current really quickly. I'm just nervous with the concept that any new package go directly into curr. remember that setup has prev/curr/test re-established and functional ( I still need feedback on whether the behaviour is intuitive, and to update upset to create prev and test automatically). Anyway, at the end of the day, this ain't my problem. Put stuff directly into curr. Good luck. Rob
Re: Units
On Fri, Dec 21, 2001 at 03:27:33PM +1100, Robert Collins wrote: - Original Message - From: Christopher Faylor [EMAIL PROTECTED] I don't see how that applies to the first release of a new package. I'd call it pretty basic risk management. If the package doesn't cause any havoc, then put it in current really quickly. I'm just nervous with the concept that any new package go directly into curr. But, I still don't understand what you expect to happen. Do you think that a non-adventurous person would be interested in the package but would pass on it because it says Test and would therefore potentially be saved from disaster? Or, conversely, are you expecting that there is a group of people who would be interested in downloading Test versions and providing useful feedback for first time package providers? I just think of this as It's a new package. Since it's brand new, it could have bugs. If you want people to try the package then don't put any barriers in the path of downloading it. Maybe if this was the first release of a disk optimization tool or something, I could see a need to be very careful. But, so far this discussion has been wrt a program which generates large characters and a program which converts between various systems of units. The *only* thing I can think of that would require care with packages like these would be to ensure that they didn't overwrite other parts of cygwin's installation. I can see that becoming more of an issue as time progresses. But, that's something that should be handled in software, not by end-users downloading test versions. Btw, I think Earnie's idea of having a *New!* category is actually a good one. I have been meaning to implement something like that for the web package lister, in fact. cgf
Re: Units
=== - Original Message - From: Christopher Faylor [EMAIL PROTECTED] Btw, I think Earnie's idea of having a *New!* category is actually a good one. I have been meaning to implement something like that for the web package lister, in fact. Yes. I intend to do that for setup once we have a persistent database of whats available - anything added since the last actual installation activity would be added to 'New'. Rob
Re: Units
On Fri, Dec 21, 2001 at 04:25:49PM +1100, Robert Collins wrote: === - Original Message - From: Christopher Faylor [EMAIL PROTECTED] Btw, I think Earnie's idea of having a *New!* category is actually a good one. I have been meaning to implement something like that for the web package lister, in fact. Yes. I intend to do that for setup once we have a persistent database of whats available - anything added since the last actual installation activity would be added to 'New'. It's a little more problematic for the web page, though, unless I use cookies. Mmm... cookies. cgf
Re: Units
=== - Original Message - From: Christopher Faylor [EMAIL PROTECTED] What about New within the last _x_ days ? Then it's up to the user. Rob
RE: Units
Thanks. btw - did you have a look at the bash completion script I posted about the other day? -Original Message- From: Robert Collins [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 19 December 2001 10:27 am To: Gary R. Van Sickle; [EMAIL PROTECTED] Subject: Re: Units Sounds like John + 2 for , and 34 in apathy :}. If no one objects by the weekend it can go in. I certainly can't help validate the package etc until then. If someone else wants to , that's cool by me. Rob === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
RE: bash completion (was: RE: Units)
OK, The setup.hint and bz2 packages can be found at: http://www.straylight.eu.org/~carl/bash_completion/ Here's the hint file... sdesc: A script of Bash completion rules. ldesc: A relatively new feature in bash is programmable completion, which has been available since the beta version of 2.04. This extends the built in filename completion to programs such as ssh and cvs. http://www.caliban.org/bash/index.shtml#completion.; test: 1.0-1 category: Utils requires: bash J. === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
RE: bash completion (was: RE: Units)
Thats not what the help file says... Note that category names may be multi-word, e.g., ASCII Games but, currently all categories are only a single word. J -Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 19 December 2001 3:47 pm To: Earnie Boyd Cc: Morrison, John; '[EMAIL PROTECTED]' Subject: Re: bash completion (was: RE: Units) Earnie Boyd wrote: I think that `category: Utils' is too generic. I'd prefer Misc but that's reserved. How about `category: Shell Utils'? In the current grammar, `category: Shell Utils' means that the package is a member of both the `Shell' and the `Utils' categories. If we are going to invent new categories, at LEAST let us not repeat Microsoft's Program Files disaster and refrain from using categories with spaces in them --Chuck === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
Re: bash completion (was: RE: Units)
Morrison, John wrote: Thats not what the help file says... Note that category names may be multi-word, e.g., ASCII Games but, currently all categories are only a single word. I know that. category: Shell Utils is two categories. category: Shell Utils is one category. (Earnie's example was the former, not the latter -- hence, two categories) It is POSSIBLE to have a space in the category name, but you must quote properly. Just like it is POSSIBLE to have a space in a directory name (Program Files) -- but it causes no END of headaches. I am saying: please let us not do this. Stay with oneword category names. Hungarian-ize them if we must: ShellUtils --Chuck
Re: bash completion (was: RE: Units)
On Wed, Dec 19, 2001 at 12:16:58PM -, Morrison, John wrote: -Original Message- From: Robert Collins [mailto:[EMAIL PROTECTED]] - Original Message - From: Morrison, John [EMAIL PROTECTED] It is fun. A couple of questions for you wrt setup.hint... category: the best I can think of is Utils... is this OK? requires: cygwin (obviously) and bash. It requires bash 2.05a - how do I specify versions in the requires section? You cannot (yet). As for cygwin, unless it has .dll or .exe's linked against cygwin, it does not require cygwin. Other than that, the setup.hint looks good to me. Rob I thought The requires line indicates the packages that this package relies on. If your package is dependent on a file provided by another package that other package should be included here - this includes the cygwin package itself! implied that *everything* required cygwin...? I'm not sure how you got that impression. This includes the cygwin package itself would be applied to If your package is dependent on a file. So, if your package is not dependent on anything in the cygwin package there is not reason to include the cygwin package. If the intent was to say Always include the cygwin package then it would have been a lot clearer to say that. I'd clarify this if I understood why this is confusing. cgf
Re: bash completion (was: RE: Units)
On Wed, Dec 19, 2001 at 11:04:22AM -0500, Charles Wilson wrote: Morrison, John wrote: Thats not what the help file says... Note that category names may be multi-word, e.g., ASCII Games but, currently all categories are only a single word. I know that. category: Shell Utils is two categories. category: Shell Utils is one category. (Earnie's example was the former, not the latter -- hence, two categories) It is POSSIBLE to have a space in the category name, but you must quote properly. Just like it is POSSIBLE to have a space in a directory name (Program Files) -- but it causes no END of headaches. I am saying: please let us not do this. Stay with oneword category names. Hungarian-ize them if we must: ShellUtils I hate to be a wet blanket about this but I'm not convinced that this package belongs in the distribution. It seems too narrow in scope for its own package. Is there anything similar to this in Red Hat, Debian, SuSE, etc.? cgf
Re: FW: bash completion (was: RE: Units)
On Wed, Dec 19, 2001 at 01:58:55PM -, Ebrey, Carl wrote: Gah! I meant to send this to the list but I replied and so it went to Earnie instead. Sorry about that... Okay, I could be really wrong here but from what I can see, http://cygwin.com/setup.html doesn't mention any Shell Utils category. What it does quite clearly state is, Please do not invent a new category without checking with the cygwin-apps mailing list first. Does that mean that we should consider that to be a proposal for a new category? :) As Chuck has pointed out, we are clearly not going to approve a category which is essentially a concatenation of two existing categories. And, it doesn't make sense to me to use this particular package for a departure from current practices. cgf
RE: bash completion (was: RE: Units)
I have to admit that I thought it was quite confusing too. Perhaps if it said, This rule also applies to Cygwin itself because Cygwin is also a package? Just my 2p/c/whatever. Carl -Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 19, 2001 4:13 PM To: [EMAIL PROTECTED] Subject: Re: bash completion (was: RE: Units) snip I'm not sure how you got that impression. This includes the cygwin package itself would be applied to If your package is dependent on a file. So, if your package is not dependent on anything in the cygwin package there is not reason to include the cygwin package. If the intent was to say Always include the cygwin package then it would have been a lot clearer to say that. I'd clarify this if I understood why this is confusing. cgf === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
RE: bash completion (was: RE: Units)
The same could be said for many people where the sender is [EMAIL PROTECTED] Carl -Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 19, 2001 4:31 PM To: [EMAIL PROTECTED] Subject: Re: bash completion (was: RE: Units) On Wed, Dec 19, 2001 at 04:25:36PM -, Ebrey, Carl wrote: Is there no way that the list program can rewrite the reply-to line? That would Make Things Easier(TM), IMHO of course :) How about if I just block any email that mentions Reply-To? That would make things a lot easier for me. cgf === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
RE: bash completion (was: RE: Units)
That's what the webpage implies. If that's not what it means, then surely you have to agree that the page is confusing. Carl -Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 19, 2001 4:30 PM To: [EMAIL PROTECTED] Subject: Re: bash completion (was: RE: Units) On Wed, Dec 19, 2001 at 04:21:17PM -, Ebrey, Carl wrote: I have to admit that I thought it was quite confusing too. Perhaps if it said, This rule also applies to Cygwin itself because Cygwin is also a package? Now, *that's* confusing. So the cygwin package should say @ cygwin requires: cygwin ? cgf === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
Re: FW: bash completion (was: RE: Units)
Christopher Faylor wrote: On Wed, Dec 19, 2001 at 01:58:55PM -, Ebrey, Carl wrote: Gah! I meant to send this to the list but I replied and so it went to Earnie instead. Sorry about that... Okay, I could be really wrong here but from what I can see, http://cygwin.com/setup.html doesn't mention any Shell Utils category. What it does quite clearly state is, Please do not invent a new category without checking with the cygwin-apps mailing list first. Does that mean that we should consider that to be a proposal for a new category? :) As Chuck has pointed out, we are clearly not going to approve a category which is essentially a concatenation of two existing categories. And, it doesn't make sense to me to use this particular package for a departure from current practices. Let's not stray from the intent of my original reply. Ok, bad choice of verbiage. My intent was to say that Utils is the wrong category for this Shell specific package. What should that category be instead? How about 'Others' or 'Contrib' or ? Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: bash completion (was: RE: Units)
On Wed, Dec 19, 2001 at 04:25:36PM -, Ebrey, Carl wrote: Is there no way that the list program can rewrite the reply-to line? That would Make Things Easier(TM), IMHO of course :) How about if I just block any email that mentions Reply-To? That would make things a lot easier for me. cgf
Re: bash completion (was: RE: Units)
On Wed, Dec 19, 2001 at 04:32:16PM -, Ebrey, Carl wrote: The same could be said for many people where the sender is [EMAIL PROTECTED] In case it wasn't clear the Reply-To question has come up *repeatedly*. There is even a web page which discusses it. cgf -Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 19, 2001 4:31 PM To: [EMAIL PROTECTED] Subject: Re: bash completion (was: RE: Units) On Wed, Dec 19, 2001 at 04:25:36PM -, Ebrey, Carl wrote: Is there no way that the list program can rewrite the reply-to line? That would Make Things Easier(TM), IMHO of course :) How about if I just block any email that mentions Reply-To? That would make things a lot easier for me. cgf
Re: bash completion (was: RE: Units)
On Wed, Dec 19, 2001 at 04:31:40PM -, Ebrey, Carl wrote: That's what the webpage implies. If that's not what it means, then surely you have to agree that the page is confusing. I guess now I understand at least one specific confusion. Robert already clarified the intent of the section. Go back and read his reply to John. He wasn't saying that the cygwin package has to rely on itself. I guess I'll take a stab at adding more words. cgf
Re: bash completion (was: RE: Units)
Christopher Faylor wrote: Is there anything similar to this in Red Hat, Debian, SuSE, etc.? Well, /etc/profile, hosts, passwd, group and other core config files are owned by the 'setup' package in Red Hat Linux. Then there's the initscripts package for the rc.d directory. And most of the other files are owned by individual packages, like bash owns /etc/bashrc. My point is, RHL doesn't set any particular standard. If anything, I'd give /etc/bash_completions to bash -- it's only useful when you install bash, and you have to upgrade bash to 2.05 or higher to use the completions. -- = ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m
RE: bash completion (was: RE: Units)
-Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 19 December 2001 4:17 pm To: [EMAIL PROTECTED] Subject: Re: bash completion (was: RE: Units) On Wed, Dec 19, 2001 at 11:04:22AM -0500, Charles Wilson wrote: Morrison, John wrote: Thats not what the help file says... Note that category names may be multi-word, e.g., ASCII Games but, currently all categories are only a single word. I know that. category: Shell Utils is two categories. category: Shell Utils is one category. (Earnie's example was the former, not the latter -- hence, two categories) It is POSSIBLE to have a space in the category name, but you must quote properly. Just like it is POSSIBLE to have a space in a directory name (Program Files) -- but it causes no END of headaches. I am saying: please let us not do this. Stay with oneword category names. Hungarian-ize them if we must: ShellUtils I hate to be a wet blanket about this but I'm not convinced that this package belongs in the distribution. It seems too narrow in scope for its own package. Fair enough - I found it today and found it useful. I thought one of the purposes of this list was to question whether an app would be a nice addition. Is there anything similar to this in Red Hat, Debian, SuSE, etc.? Don't know. Sorry - I don't have a linux box! J. cgf === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
Re: bash completion (was: RE: Units)
On Wed, Dec 19, 2001 at 10:13:35AM -0700, Warren Young wrote: Christopher Faylor wrote: Is there anything similar to this in Red Hat, Debian, SuSE, etc.? Well, /etc/profile, hosts, passwd, group and other core config files are owned by the 'setup' package in Red Hat Linux. Then there's the initscripts package for the rc.d directory. And most of the other files are owned by individual packages, like bash owns /etc/bashrc. My point is, RHL doesn't set any particular standard. If anything, I'd give /etc/bash_completions to bash -- it's only useful when you install bash, and you have to upgrade bash to 2.05 or higher to use the completions. That's where I would be leaning, too. I think it makes sense to include the completions in bash. Or maybe in shellutils? The only problem with this that I can see is that they'll be more hidden there. If they are a separate setup.exe package then it is more likely that someone will notice them and say Hey, cool! and install them. If they just slide in with a bash installation then, unless we make them the default, it's more likely that people won't know what they have unless they're reminded about it on the mailing list (or whereever). Hmm. Maybe I just convinced myself that they belong as a separate package. cgf
Re: bash completion (was: RE: Units)
On Wed, Dec 19, 2001 at 04:28:28PM -, Morrison, John wrote: -Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 19 December 2001 4:17 pm To: [EMAIL PROTECTED] Subject: Re: bash completion (was: RE: Units) I hate to be a wet blanket about this but I'm not convinced that this package belongs in the distribution. It seems too narrow in scope for its own package. Fair enough - I found it today and found it useful. I thought one of the purposes of this list was to question whether an app would be a nice addition. It is. This was part of my response to the question. I'm not going to veto anything if the consensus is that it's useful. I can, in fact, see why it would be useful. cgf
fortune-1.8-1 [was Re: bash completion (was: RE: Units)]
On Wed, Dec 19, 2001 at 12:26:00PM -0500, Christopher Faylor wrote: On Wed, Dec 19, 2001 at 04:28:28PM -, Morrison, John wrote: Fair enough - I found it today and found it useful. I thought one of the purposes of this list was to question whether an app would be a nice addition. It is. This was part of my response to the question. I'm not going to veto anything if the consensus is that it's useful. I can, in fact, see why it would be useful. I'd like to pour fuel into the fire of `usefulness' of a package. I'd like to contribute the NetBSD fortune package to Cygwin and therefore I'd even like to propose to add a Games section *gasp*. setup.hint: --- sdesc: Print a random, hopefully interesting, adage category: Games requires: cygwin Opinions? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: fortune-1.8-1 [was Re: bash completion (was: RE: Units)]
Corinna Vinschen wrote: I'd like to pour fuel into the fire of `usefulness' of a package. I'd like to contribute the NetBSD fortune package to Cygwin and therefore I'd even like to propose to add a Games section *gasp*. setup.hint: --- sdesc: Print a random, hopefully interesting, adage category: Games requires: cygwin Opinions? I like it. Games is fine -- didn't somebody or other port FreeCIV to cygwin about a year ago? FWIW, I'm planning to add ddate to my cygutils package eventually -- it's distributed on Linux systems as part of the util linux package along with the (already cygutils-assimilated) cal and namei programs, among others. ddate is the Druel Discordian Date program -- Today is Sweetmorn, the 42nd of Bureaucracy, 3161. etc. --Chuck
Re: fortune-1.8-1 [was Re: bash completion (was: RE: Units)]
On Wed, Dec 19, 2001 at 12:46:58PM -0500, Charles Wilson wrote: Corinna Vinschen wrote: I'd like to pour fuel into the fire of `usefulness' of a package. I'd like to contribute the NetBSD fortune package to Cygwin and therefore I'd even like to propose to add a Games section *gasp*. setup.hint: --- sdesc: Print a random, hopefully interesting, adage category: Games requires: cygwin Opinions? I like it. Games is fine -- didn't somebody or other port FreeCIV to cygwin about a year ago? Actually, Games isn't even a new category. It's listed on setup.html. I added it when I added the boffo examples to the web page since I had this vague feeling that someone might be adding a package that would qualify as a game soon. cgf
Re: bash completion (was: RE: Units)
=== - Original Message - From: Charles Wilson [EMAIL PROTECTED] Hmm. Maybe I just convinced myself that they belong as a separate package. How about this: John, why don't you create a bashutils package, to serve as a collection of (moderately) useful bash scripts and settings. For now, it could contain only bashcompletion, but later you could add -- oh, bashprompt, or something... Funnily enough, I suggested calling the package bashtools last night. Hmmm, now why was that? Rob
Re: fortune-1.8-1 [was Re: bash completion (was: RE: Units)]
- Original Message - From: Corinna Vinschen [EMAIL PROTECTED] Opinions? Cool. You've my vote. Rob
Re: bash completion (was: RE: Units)
- Original Message - From: Ebrey, Carl [EMAIL PROTECTED] One thing I would like to say though is that I've been quite annoyed by the attitudes that come over on this mailing list. The last time I checked Cygwin was an open project, available for anyone to contribute and offer help. However, all I've seen is help being thrown back in people's faces, including my own. If you don't want people to help, don't have an open project. It's quite simple. Please remember that there is a difference between open project and anarchy. We do accept help. Lots of it. And I, for one, do appreciate it and try to show that appreciation. However, some things are quite annoying - and getting old topics revisited at a rate of knots is one of those. Rob
RE: fortune-1.8-1 [was Re: bash completion (was: RE: Units)]
We've (Carl and I) have been trying to port BSD-games. Unfortunately we
haven't got it to compile fully yet :( there were even errors in the
configuration file which stop'd it running (an extra '(' in some switch
statements was the first...).
If you can do it - I don't think we'd get *any* more work done :)
J.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Robert Collins
Sent: Wednesday, 19 December 2001 9:37 pm
To: [EMAIL PROTECTED]
Subject: Re: fortune-1.8-1 [was Re: bash completion (was: RE: Units)]
- Original Message -
From: Corinna Vinschen [EMAIL PROTECTED]
Opinions?
Cool. You've my vote.
Rob
RE: bash completion (was: RE: Units)
Sure. Will do either tomorrow or Friday. J. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Charles Wilson Sent: Wednesday, 19 December 2001 5:54 pm To: [EMAIL PROTECTED] Subject: Re: bash completion (was: RE: Units) Christopher Faylor wrote: That's where I would be leaning, too. I think it makes sense to include the completions in bash. Or maybe in shellutils? The only problem with this that I can see is that they'll be more hidden there. If they are a separate setup.exe package then it is more likely that someone will notice them and say Hey, cool! and install them. If they just slide in with a bash installation then, unless we make them the default, it's more likely that people won't know what they have unless they're reminded about it on the mailing list (or whereever). Hmm. Maybe I just convinced myself that they belong as a separate package. How about this: John, why don't you create a bashutils package, to serve as a collection of (moderately) useful bash scripts and settings. For now, it could contain only bashcompletion, but later you could add -- oh, bashprompt, or something... I'm thinking something like my cygutils package, which is just a grab bag of very simple (single-source-file) utilities. (FYI, you can find bashprompt here... http://www.neuro.gatech.edu/users/cwilson/cygutils/unversioned/bashprompt/ the official site is completely flaky, so I mirrored it) --Chuck
Re: bash completion (was: RE: Units)
On Thu, Dec 20, 2001 at 08:36:52AM +1100, Robert Collins wrote: === - Original Message - From: Charles Wilson [EMAIL PROTECTED] Hmm. Maybe I just convinced myself that they belong as a separate package. How about this: John, why don't you create a bashutils package, to serve as a collection of (moderately) useful bash scripts and settings. For now, it could contain only bashcompletion, but later you could add -- oh, bashprompt, or something... Funnily enough, I suggested calling the package bashtools last night. Hmmm, now why was that? Doh. I missed this. I probably could have just agreed with this suggestion and saved myself some grief. I think that the concept makes sense regardless of the name. cgf
RE: Units
I've email'd the author - he's blessed the port. I've also asked him to keep me in touch with new versions. -Original Message- From: Robert Collins [mailto:[EMAIL PROTECTED]] Sent: Monday, 17 December 2001 11:31 am To: Morrison, John Cc: '[EMAIL PROTECTED]' Subject: RE: Units On Mon, 2001-12-17 at 22:25, Morrison, John wrote: Ah, sorry, I reply'ed to the person - not the list. Stupid Outlook. I'm for including this package. That's one I believe. Anyone else for (or against?) Rob
RE: Units
Oops. Having actually read the new setup.html I see that the @ line is now optional. Okay, so now I feel stupid and I shall see to it that I get a severe beating in order to ensure that this never happens again. Sorry 'bout that. Carl -Original Message- From: Ebrey, Carl [mailto:[EMAIL PROTECTED]] Sent: Monday, December 17, 2001 11:29 AM To: '[EMAIL PROTECTED]' Subject: RE: Units erm, I should probably add that the actual setup.hint file /does/ have @ units as the first line. Just for clarity, and all her friends :) Carl -Original Message- From: Morrison, John [mailto:[EMAIL PROTECTED]] Sent: Monday, December 17, 2001 11:26 AM To: '[EMAIL PROTECTED]' Subject: RE: Units Ah, sorry, I reply'ed to the person - not the list. Stupid Outlook. Here's the setup.hints file embeded :) sdesc: Converts between different systems of units. ldesc: Units converts between different systems of units. GNU units program converts quantities expressed in various scales to their equivalents in other scales. The units program can only handle multiplicative scale changes. For example, it cannot convert Celsius to Fahrenheit but it can convert temperature differences between those temperature scales. test: 1.77-1 category: Utils requires: cygwin Thanks for pointing this out. J. -Original Message- From: Robert Collins [mailto:[EMAIL PROTECTED]] Sent: Monday, 17 December 2001 11:22 am To: Morrison, John Cc: '[EMAIL PROTECTED]' Subject: RE: Units On Mon, 2001-12-17 at 22:20, Morrison, John wrote: Is anybody interested in this program? http://www.straylight.eu.org/~carl/units/ J. http://cygwin.com/ml/cygwin-apps/2001-12/msg00244.html is the last reference, where you committed to resending the ITP (intent to package) with the setup.hint inline rather than attached. Rob === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
Re: Units
On Mon, Dec 17, 2001 at 10:43:34PM +1100, Robert Collins wrote: On Mon, 2001-12-17 at 22:38, Ebrey, Carl wrote: Oops. Having actually read the new setup.html I see that the @ line is now optional. Okay, so now I feel stupid and I shall see to it that I get a severe beating in order to ensure that this never happens again. For such a serious transgression you deserve a public whipping. Whip. Whip. Can we get some pictures please? I want to ensure that blood was drawn. cgf
