tcsh /etc/default files
I'm not certain if I ever discussed this before, but the recent tcsh
update reminded me that I think the defaults should be changed a little
bit. First off, running the scripts in profile.d should IMHO be done in
csh.login to ensure it's only done once. Secondly the (optional)
cleaning up of the PATH variable already introduced for all POSIX shells
in base-files years ago should be replicated for tcsh. Lastly, since
/usr/bin/ and /bin are the same thing on Cygwin, one of them is
redundant and placement of /usr/local/bin should be left at the
discretion of the user since tha directory does not exist by default on
Cygwin.
--8<---cut here---start->8---
--- /etc/defaults/etc/csh.cshrc 2022-02-03 18:25:13.0 +0100
+++ /etc/csh.cshrc 2019-06-02 19:07:20.072715800 +0200
@@ -3,16 +3,6 @@
#
onintr -
-if ( -d /etc/profile.d ) then
- set nonomatch
- foreach _s ( /etc/profile.d/*.csh )
-if ( -r $_s ) then
- source $_s
-endif
- end
- unset _s nonomatch
-endif
-
if (! ${?prompt}) goto end
# This is an interactive session
--- /etc/defaults/etc/csh.login 2022-02-03 18:25:13.0 +0100
+++ /etc/csh.login 2019-06-02 19:07:19.229253700 +0200
@@ -4,7 +4,21 @@
unsetenv TEMP
unsetenv TMP
-set path=( /usr/local/bin /usr/bin /bin $path:q )
+set winpath = ( $path:q )
+if ( ${?CYGWIN_NOWINPATH} ) then
+ set path=( /usr/bin )
+else
+ set path=( /usr/bin $path:q )
+endif
+if ( -d /etc/profile.d ) then
+ set nonomatch
+ foreach _s ( /etc/profile.d/*.csh )
+if ( -r $_s ) then
+ source $_s
+endif
+ end
+ unset _s nonomatch
+endif
if ( ! ${?USER} ) then
set user="`id -un`"
--8<---cut here---end--->8---
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: Go or Rust Packages?
Marco Atzeri writes: > As it is written in go, you need to go back to the oldest version > written in C and from them forward to the current version. No you don't. Upstream opines that they already support Windows and Linux and thusly do not need Cygwin. The details vary, but Rust climbed up the same tree. Go might be salvageable if the go frontend to go is usable, I haven't had time to look at that. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: python-cryptography >= 3.4.0 and Rust
On 04.02.2022 16:28, Allen Hewes wrote: -Original Message- Welp, then the wheels came off. I am assuming that Cygwin's python- cryptography is still at 3.3.2 b/c of this Rust issue? Hi Allen, it is correct. I released the last version that was still on C It's still on C but the authors have been adding new features in Rust. They are using the Python Rust API bridge for the integration between the two. It seems not an optional feature, without a Rust compiler it can not be built Rust is making more in-roads into software I use frequently or like to use. Is there any efforts or discussions about getting Rust able to target Cygwin? Not that I aware of. We have already problem to update clang that is already behind. Many of the shiny new sysadmin/sysutils are written in Rust or Go. The reason why I brought up python cryptography and Cygwin is that the current version of python cryptography doesn't support OpenSSL 3 (AFAIK). Only the most recent cryptography does. At some point in the future, this will have to be addressed, wouldn't it (IMHO)? Python cryptography is fundamental in the Python ecosystem. Pythonistas who use Cygwin will need an update to cryptography. How can this happen? "Somebody Has To Do It" https://cygwin.com/acronyms/#SHTDI but I do not volounteer ... Rust and Go are purely wish, they both requires specific expertize and time. ...except for then those languages make in-roads into the bits/ecosystem that Cygwin has packaged/supported (for a long time in some cases). From what I can tell, these ecosystems think WSL/WSL2 is their "best effort" for Linux-y (or POSIX) on Windows. Feel free to work on it Based on the conversation in rigrep (a Rust grepper), it sounds like it's a large amount of work that would not be accepted/entertained by upstream: https://github.com/BurntSushi/ripgrep/issues/269 in the old past we had some discussion on cmake but finally upstream accepted our efforts. /allen Regards Marco
Re: Go or Rust Packages?
On 04.02.2022 10:23, Jan Nijtmans wrote: Op vr 4 feb. 2022 om 07:58 schreef Marco Atzeri: As it is written in go, you need to go back to the oldest version written in C and from them forward to the current version. There's also a "golang" frontend for gcc. Could that be used to bootstrap go? Regards, Jan Nijtmans no idea. I leave the question to the GCC experts: Achim Gratz/Jonathan Yong
RE: python-cryptography >= 3.4.0 and Rust
> -Original Message- > From: Cygwin-apps > On Behalf Of Marco Atzeri > Sent: Friday, February 4, 2022 1:52 AM > To: cygwin-apps@cygwin.com > Subject: Re: python-cryptography >= 3.4.0 and Rust > > On 03.02.2022 23:11, Allen Hewes wrote: > > Hi @all, > > > > I use Cygwin pretty much like Linux in/on my Windows machines. Meaning, > I am not using it for POSIX reasons. I do like Cygwin a lot, I prefer Cygwin > over > WSL/WSL2. > > > > A PyPI package I wanted to use has a hard dependency on > cryptography>=35.0. > > > > So I downloaded the Cygwin source for python-cryptography and got to > work on updating it to 35.0. > > > > Welp, then the wheels came off. I am assuming that Cygwin's python- > cryptography is still at 3.3.2 b/c of this Rust issue? > > > > Hi Allen, > it is correct. I released the last version that was still on C > It's still on C but the authors have been adding new features in Rust. They are using the Python Rust API bridge for the integration between the two. > > Rust is making more in-roads into software I use frequently or like to use. > > Is > there any efforts or discussions about getting Rust able to target Cygwin? > > Not that I aware of. > We have already problem to update clang that is already behind. > Many of the shiny new sysadmin/sysutils are written in Rust or Go. The reason why I brought up python cryptography and Cygwin is that the current version of python cryptography doesn't support OpenSSL 3 (AFAIK). Only the most recent cryptography does. At some point in the future, this will have to be addressed, wouldn't it (IMHO)? Python cryptography is fundamental in the Python ecosystem. Pythonistas who use Cygwin will need an update to cryptography. How can this happen? > Rust and Go are purely wish, they both requires specific expertize and time. > ...except for then those languages make in-roads into the bits/ecosystem that Cygwin has packaged/supported (for a long time in some cases). From what I can tell, these ecosystems think WSL/WSL2 is their "best effort" for Linux-y (or POSIX) on Windows. > Feel free to work on it Based on the conversation in rigrep (a Rust grepper), it sounds like it's a large amount of work that would not be accepted/entertained by upstream: https://github.com/BurntSushi/ripgrep/issues/269 /allen Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender.
Re: Go or Rust Packages?
Op vr 4 feb. 2022 om 07:58 schreef Marco Atzeri: > As it is written in go, you need to go back to the oldest version > written in C and from them forward to the current version. There's also a "golang" frontend for gcc. Could that be used to bootstrap go? Regards, Jan Nijtmans
Re: Go or Rust Packages?
On Feb 4 00:14, Mark Geisert wrote: > Brian Inglis wrote: > > On 2022-02-02 02:44, Corinna Vinschen wrote: > > > On Feb 1 21:22, Adam Dinwoodie wrote: > > > > The upstream fzf package moved from Ruby to Go some time ago. I had > > > > vague but noble intetions to try to maintain a fork on the basis of the > > > > last version of the Ruby code, but never managed anything useful. In > > > > that context, I expect it's time that I officially throw in the towel, > > > > and mark fzf as orphaned. > > > > > > > > The existing build still works, and I don't think there's likely to be > > > > any crass security problems or anything like that. But there's no > > > > longer any upstream support, and I clearly don't have the capacity to > > > > properly maintain it solo. > > > > > > > > I'm not quite sure what the process is here, but I suspect it's just a > > > > case of someone with the appropriate access making an update to > > > > https://cygwin.com/cygwin-pkg-maint > > > > Anyone know of anyone trying to build Go or Rust on Cygwin? > I made some progress with Go on Cygwin a couple years ago, but had to give > up because it required more time than I could give it. I got about 1/3 of > the way through it. The last straw was its need for syscall?() and Cygwin > not having those functions (or a need for them). It was a lot of looking > for "#ifdef Windows" and usually adding "&& !defined(__CYGWIN__)". The goal > still tantalizes though... You might be better off writing a syscall layer which translates the expected syscalls into standard POSIX API calls. Cygwin could even provide that in the long run. Ages ago we discussed converting cygwin1.dll to cygwin2.dll and only export a syscall interface with any arbitrary libc on top (e. g. glibc), but that would have been a near full re-implementation of Cygwin, so we buried the idea. However, providing a syscall layer on top might be a nice extension. Corinna
Re: Go or Rust Packages?
Brian Inglis wrote: On 2022-02-02 02:44, Corinna Vinschen wrote: On Feb 1 21:22, Adam Dinwoodie wrote: The upstream fzf package moved from Ruby to Go some time ago. I had vague but noble intetions to try to maintain a fork on the basis of the last version of the Ruby code, but never managed anything useful. In that context, I expect it's time that I officially throw in the towel, and mark fzf as orphaned. The existing build still works, and I don't think there's likely to be any crass security problems or anything like that. But there's no longer any upstream support, and I clearly don't have the capacity to properly maintain it solo. I'm not quite sure what the process is here, but I suspect it's just a case of someone with the appropriate access making an update to https://cygwin.com/cygwin-pkg-maint Anyone know of anyone trying to build Go or Rust on Cygwin? I made some progress with Go on Cygwin a couple years ago, but had to give up because it required more time than I could give it. I got about 1/3 of the way through it. The last straw was its need for syscall?() and Cygwin not having those functions (or a need for them). It was a lot of looking for "#ifdef Windows" and usually adding "&& !defined(__CYGWIN__)". The goal still tantalizes though... I don't think anybody has mentioned a need for Rust on Cygwin before. That might be easier because of a simpler runtime than Go, but still a major, major project. ..mark
