From: Eliot Moss <moss@cs.umass.edu>
To: cygwin@cygwin.com
Subject: Re: Sv: g++ and c++17 filesystem
Date: Wed, 18 Nov 2020 11:31:21 -0500 [thread overview]
Message-ID: <1f6849f1-2d79-8249-8009-d8a99daefed0@cs.umass.edu> (raw)
In-Reply-To: <c2d6280c-26e3-f9e7-89bd-693385a768b2@gmail.com>
On 11/18/2020 11:24 AM, René Berber via Cygwin wrote:
> Cygwin handles the file system with no problem, but using Posix-like notation, not Windows-like.
> End of story.
And I'll add, this is by design: Cygwin's goal is to provide a programming (and command line)
environment as much like Posix as reasonably possible.
It does include some tools to help interface with Windows more explicitly, such as cygpath and
cygstart. I have defined a bash alias ppt that refers to a bach function powerpnt, defined thusly:
powerpnt ()
{
local ARG;
[ -n "$1" ] && {
ARG="$(cygpath -wa "$1")";
shift
};
[ -n "$VERBOSE" ] && {
echo powerpnt ${ARG:+"${ARG}"} "$@"
};
command powerpnt ${ARG:+"${ARG}"} "$@" &
}
This takes the first argument and converts it from Posix to Windows form, for passing to the
powerpnt binary. And then I have a file system link so that "command powerpnt" gets to the
installed Windows binary C:\Program Files.
But this is by far the exception as opposed to the rule in how I use Cygwin.
In hope that this give you some perspective and insight as to what Cygwin is and why.
Best wishes - Eliot Moss
next prev parent reply other threads:[~2020-11-18 16:31 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-17 15:15 sten.kristian.ivarsson
2020-11-17 16:45 ` René Berber
2020-11-18 9:00 ` Sv: " sten.kristian.ivarsson
2020-11-18 16:24 ` René Berber
2020-11-18 16:31 ` Eliot Moss [this message]
2020-11-18 20:46 ` Kristian Ivarsson
2020-11-18 20:56 ` Eliot Moss
2020-11-18 21:18 ` Kristian Ivarsson
2020-11-18 23:47 ` Eliot Moss
2020-11-19 8:10 ` Sv: " sten.kristian.ivarsson
2020-11-18 21:45 ` Norton Allen
2020-11-19 0:08 ` Doug Henderson
2020-11-19 6:23 ` Brian Inglis
2020-11-19 10:03 ` Sv: " sten.kristian.ivarsson
2020-11-19 15:27 ` Brian Inglis
2020-11-20 9:37 ` Sv: " sten.kristian.ivarsson
2020-11-20 15:29 ` Brian Inglis
2020-11-20 16:11 ` Sv: " sten.kristian.ivarsson
2020-11-19 15:36 ` Eliot Moss
2020-11-20 8:31 ` Sv: " sten.kristian.ivarsson
2020-11-20 18:28 ` Jonathan Yong
[not found] ` <000601d6c173$aa55d540$ff017fc0$@gmail.com>
2020-11-23 11:09 ` Sv: " Jonathan Yong
2020-11-24 9:32 ` Sv: " sten.kristian.ivarsson
2020-11-24 10:24 ` Jonathan Yong
2020-11-24 11:35 ` Sv: " sten.kristian.ivarsson
2020-11-24 12:33 ` Jonathan Yong
2020-11-24 14:01 ` Sv: " sten.kristian.ivarsson
2020-11-25 2:25 ` Jonathan Yong
2020-11-24 13:22 ` Eliot Moss
2020-11-24 14:31 ` Sv: " sten.kristian.ivarsson
2020-11-24 20:06 ` Ken Brown
2020-11-24 20:39 ` Eliot Moss
2020-11-25 8:02 ` Sv: " sten.kristian.ivarsson
2020-11-25 8:30 ` sten.kristian.ivarsson
2020-11-25 0:23 ` Brian Inglis
2020-11-25 9:00 ` Sv: " sten.kristian.ivarsson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1f6849f1-2d79-8249-8009-d8a99daefed0@cs.umass.edu \
--to=moss@cs.umass.edu \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).