On Sat, Dec 10, 2016 at 5:40 AM, Marko Rauhamaa wrote:
>> How do you represent the current and previous directory in a list
>> without reserving identifiers for them?
>
> My idea covered absolute pathnames only.
Well, you're going to need to cope with relative pathnames somehow. I
suppose you cou
Steve D'Aprano :
> On Fri, 9 Dec 2016 09:34 pm, Marko Rauhamaa wrote:
>> Steve D'Aprano :
>>> No that's incorrect. It isn't that . and .. are forbidden, but they
>>> are reserved: every single directory in Unix file systems have a .
>>> and .. directory entry. So they are legitimate directory name
On Fri, 9 Dec 2016 09:34 pm, Marko Rauhamaa wrote:
> Steve D'Aprano :
>
>> On Fri, 9 Dec 2016 04:52 pm, Marko Rauhamaa wrote:
>>> In Linux, "." and ".." are taboo.
>>
>> No that's incorrect. It isn't that . and .. are forbidden, but they are
>> reserved: every single directory in Unix file system
eryk sun :
> Windows NTFS doesn't normalize names to a canonical form. It also
> allows lone surrogate codes, which is invalid UTF-16.
Somewhat related, surrogate codes are invalid Unicode and shouldn't be
allowed in Unicode strings. However, Python does allow them.
Marko
--
https://mail.pytho
On Fri, Dec 9, 2016 at 7:41 AM, Steve D'Aprano
wrote:
> Frankly, I think that Apple HFS+ is the only modern file system that gets
> Unicode right. Not only does it restrict file systems to valid UTF-8
> sequences, but it forces them to a canonical form to avoid the é é gotcha,
> and treats file n
On Fri, Dec 9, 2016 at 6:41 PM, Steve D'Aprano
wrote:
> On Fri, 9 Dec 2016 01:52 pm, Chris Angelico wrote:
>
>> On Fri, Dec 9, 2016 at 12:34 PM, BartC wrote:
>>> With a case-sensitive file system, how do you search only for 'harry',
>>> not knowing what combinations of upper and lower case have b
Steve D'Aprano :
> On Fri, 9 Dec 2016 04:52 pm, Marko Rauhamaa wrote:
>> In Linux, "." and ".." are taboo.
>
> No that's incorrect. It isn't that . and .. are forbidden, but they are
> reserved: every single directory in Unix file systems have a . and ..
> directory entry. So they are legitimate
On Fri, 9 Dec 2016 04:52 pm, Marko Rauhamaa wrote:
> Random832 :
>
>> On Thu, Dec 8, 2016, at 20:38, Dennis Lee Bieber wrote:
>>> In the original 8.3 scheme -- no files "contained" a dot
>>
>> Yes, but they do now, and the compatibility quirks persist.
>
> When porting a Python program to Window
On Fri, 9 Dec 2016 01:52 pm, Chris Angelico wrote:
> On Fri, Dec 9, 2016 at 12:34 PM, BartC wrote:
>> With a case-sensitive file system, how do you search only for 'harry',
>> not knowing what combinations of upper and lower case have been used?
>> (It's a good thing Google search isn't case sens
Random832 :
> On Thu, Dec 8, 2016, at 20:38, Dennis Lee Bieber wrote:
>> In the original 8.3 scheme -- no files "contained" a dot
>
> Yes, but they do now, and the compatibility quirks persist.
When porting a Python program to Windows, I noticed the filename "aux"
is not allowed in Windows.
Chris Angelico :
> On Fri, Dec 9, 2016 at 10:03 AM, Marko Rauhamaa wrote:
>> I find it a bit annoying that "/" cannot be used in Linux filenames.
>> Slashes have very common everyday uses and it's a pity they are
>> reserved. Instead, ASCII control characters are allowed, which is of
>> no use.
>
On Thu, Dec 8, 2016, at 20:38, Dennis Lee Bieber wrote:
> On Thu, 08 Dec 2016 10:37:27 -0500, Random832
> declaimed the following:
> >There are other issues, like needing a way to do Windows' version of
> >wildcard parsing with all its quirks, or at least some of its quirks -
> >"*.*" for all file
On Fri, 9 Dec 2016 12:32 pm, Dennis Lee Bieber wrote:
> There is always VMS:
>
> volume:[dir.sub.subsub]fn.ext;ver
>
> (where volume could be a hardware device or a logical name -- which is NOT
> the same as an environment variable; only other place I've seen something
> similar is the Amiga --
On Fri, Dec 9, 2016 at 12:34 PM, BartC wrote:
> With a case-sensitive file system, how do you search only for 'harry', not
> knowing what combinations of upper and lower case have been used? (It's a
> good thing Google search isn't case sensitive!)
This is handled by "case correlations", which ar
With a case-sensitive file system, how do you search only for 'harry', not
knowing what combinations of upper and lower case have been used? (It's a
good thing Google search isn't case sensitive!)
On Linux, I'd do "find . -iname harry". A lot, but not all, of the tools
usually have options to igno
On 09/12/2016 00:55, Chris Angelico wrote:
On Fri, Dec 9, 2016 at 10:19 AM, BartC wrote:
So it it perfectly possible to have case conversion defined for English,
while other alphabets can do what they like.
And there we have it. Not only do you assume that English is the
only thing that
On Fri, Dec 9, 2016 at 10:19 AM, BartC wrote:
> I get this (although I suspect Thunderbird will screw up the tabs); the code
> I used follows at the end:
Actually it came through just fine. Although, point of note: the case
conversions of individual characters are not the same as the case
conver
On 12/08/2016 04:19 PM, BartC wrote:
> What were we talking about again? Oh yes, belittling me because I work
> with Windows!
Yes it's kind of getting that way, which means this conversation is at
an end. I don't think Chris or Steven or anyone else who has gone round
and round with you has mean
On 12/08/2016 02:46 PM, Gregory Ewing wrote:
> Michael Torrie wrote:
>> For example, on Macs,
>> control-key is not normally used, but rather the Command-key (the apple
>> key) which happens to be where the Alt key is on our PC keyboards.
>
> Actually, Alt is usually mapped to Option on a Mac. The
On Fri, Dec 9, 2016 at 10:03 AM, Marko Rauhamaa wrote:
> I find it a bit annoying that "/" cannot be used in Linux filenames.
> Slashes have very common everyday uses and it's a pity they are
> reserved. Instead, ASCII control characters are allowed, which is of no
> use.
How would you do otherwi
On 08/12/2016 22:31, Chris Angelico wrote:
On Fri, Dec 9, 2016 at 8:42 AM, BartC wrote:
Python3 tells me that original, lower-case and upper-case versions are:
ßẞıİiIÅσςσ
ßßıi̇iiåσςσ
SSẞIİIIÅΣΣΣ
Now lower-case the upper-case version and see what you get. And
upper-case the lower-case version
Gregory Ewing :
> Grant Edwards wrote:
>> But _paths_ can, and Windows command-line apps and shells choke on
>> paths when written with "/" separators because way-back when the
>> MS-DOS "designers" decided to use "/" as the default option
>> character.
>
> To be fair to them, the use of "/" for o
On Fri, Dec 9, 2016 at 8:42 AM, BartC wrote:
> Python3 tells me that original, lower-case and upper-case versions are:
>
> ßẞıİiIÅσςσ
> ßßıi̇iiåσςσ
> SSẞIİIIÅΣΣΣ
Now lower-case the upper-case version and see what you get. And
upper-case the lower-case version. Because x.upper().lower() should be
Michael Torrie wrote:
For example, on Macs,
control-key is not normally used, but rather the Command-key (the apple
key) which happens to be where the Alt key is on our PC keyboards.
Actually, Alt is usually mapped to Option on a Mac. The Mac
Command key corresponds the "Windows" or "Meta" key
On 08/12/2016 19:36, Chris Angelico wrote:
On Fri, Dec 9, 2016 at 6:15 AM, BartC wrote:
On 08/12/2016 03:41, Steven D'Aprano wrote:
On Thursday 08 December 2016 12:15, BartC wrote:
That's all. I know the value of keeping things straightforward instead
of throwing in everything you can thi
Michael Torrie wrote:
Interesting. I wouldn't have thought ENTER would return a line feed.
Possibly you have the terminal in "cbreak" mode, which
provides a character at a time but still does things
like translate CR->LF.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Grant Edwards wrote:
But _paths_ can, and Windows command-line apps and shells choke on
paths when written with "/" separators because way-back when the
MS-DOS "designers" decided to use "/" as the default option character.
To be fair to them, the use of "/" for options can be traced
back to ea
On Fri, Dec 9, 2016 at 8:15 AM, Gregory Ewing
wrote:
> The main difference is that you're unlikely to accidentally
> get a million file names or 131072 bytes of arguments that
> way. :-)
python3 argcount.py
{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}
65537
Ch
Random832 wrote:
Just to point out, brace expansion isn't globbing. The most important
difference is that brace expansion doesn't care what files exist.
However, it's something that the shell expands into multiple
arguments, giving it similar characteristics for the purposes
of this discussion.
On Fri, Dec 9, 2016 at 6:15 AM, BartC wrote:
> On 08/12/2016 03:41, Steven D'Aprano wrote:
>>
>> On Thursday 08 December 2016 12:15, BartC wrote:
>>
>
>>> That's all. I know the value of keeping things straightforward instead
>>> of throwing in everything you can think of. The file-matching is don
On 08/12/2016 03:41, Steven D'Aprano wrote:
On Thursday 08 December 2016 12:15, BartC wrote:
That's all. I know the value of keeping things straightforward instead
of throwing in everything you can think of. The file-matching is done by
WinAPI functions.
So you're happy with the fact that
On 12/08/2016 10:05 AM, Grant Edwards wrote:
> Or various other terminal emulators tha are mostly ANSI and Unicode
> aware...
>
> And the Linux console...
True.
>
> It's interesting to note that the "real" xterm terminal emulator will
> still emulate a Tektronix storage-scope graphics terminal
On 2016-12-08, eryk sun wrote:
> On Thu, Dec 8, 2016 at 4:34 PM, Grant Edwards
> wrote:
>>
>> So, to avoid _that_ problem, Windows command line apps and the cmd.exe
>> shell only allow "\" as a path separator.
>
> In cmd you can usually clarify the intent with quotes, e.g. `dir
> C:/Windows` fai
On Thu, Dec 8, 2016 at 4:34 PM, Grant Edwards wrote:
>
> So, to avoid _that_ problem, Windows command line apps and the cmd.exe
> shell only allow "\" as a path separator.
In cmd you can usually clarify the intent with quotes, e.g. `dir
C:/Windows` fails because it parses "Windows" as a parameter
On 2016-12-08, Michael Torrie wrote:
> Now we mostly just use one terminal type, "xterm."
Or various other terminal emulators tha are mostly ANSI and Unicode
aware...
And the Linux console...
It's interesting to note that the "real" xterm terminal emulator will
still emulate a Tektronix storag
On 12/08/2016 09:35 AM, Michael Torrie wrote:
> Yes Control codes are, well control codes. Any ascii value under 32.
> They are more or less common across terminal types. I don't know of any
> way around that with terminals.
That is to say that on all terminal types that I'm aware of, the ENTER
On Thursday December 8 2016 11:48, in comp.lang.python, "Random832"
wrote:
> On Wed, Dec 7, 2016, at 15:29, Lew Pitcher wrote:
>> But, point of fact is that the feature to disable globbing is not often
>> needed. Most Unix programs that accept filenames are happy to accept a
>> list of filenames.
On Wed, Dec 7, 2016, at 22:41, Steven D'Aprano wrote:
> Python's fnmatch lib is a good example. It has, or at least had, no
> support for escaping metacharacters. Anyone relying on Python's fnmatch and
> glob
> modules alone for globbing will be unable to handle legitimate file names.
That's not
On Wed, Dec 7, 2016, at 15:29, Lew Pitcher wrote:
> But, point of fact is that the feature to disable globbing is not often
> needed. Most Unix programs that accept filenames are happy to accept a
> list of filenames. There is not much call for a program to perform it's own
> globbing, like is requ
On 12/08/2016 05:43 AM, BartC wrote:
> (Neither will see Shift+Ctrl+B, which means go to start of the file,
> same as Ctrl+Home. Ubuntu sees Ctrl+Home, but not Debian, although it
> will report Alt+Home. And some laptop keyboards already have Home on an
> Alternate-Function shift! It's a mess.)
On 2016-12-08, Random832 wrote:
> On Wed, Dec 7, 2016, at 03:50, Peter Otten wrote:
>> Is there an equivalent to
>>
>> # touch -- -r
>>
>> on Windows?
>
> Doesn't need one - options conventionally start with /, and filenames
> can't contain /.
But _paths_ can, and Windows command-line apps and
On Wed, Dec 7, 2016, at 03:50, Peter Otten wrote:
> Is there an equivalent to
>
> # touch -- -r
>
> on Windows?
Doesn't need one - options conventionally start with /, and filenames
can't contain /.
--
https://mail.python.org/mailman/listinfo/python-list
On Wed, Dec 7, 2016, at 00:15, Steven D'Aprano wrote:
> and the shell expands the metacharacters ? {...} * [...] regardless of
> how much
> smarts the command itself has.
>
> There are thousands of programs I might use, and they may implement who
> knows
> how many different globbing rules:
>
>
On Thu, Dec 8, 2016, at 01:20, Gregory Ewing wrote:
> BartC wrote:
> > And globbing doesn't take care of all of it: a Linux program still has
> > to iterate over a loop of filenames. The same as on Windows, except the
> > latter will need to call a function to deliver the next filename.
>
> Actu
BartC wrote:
Run the code below and start pressing keys. On both of my Linuxes, I get
escape sequences shown when I Insert, Delete, Home, End, Page Up, Page
Down, Up, Down, Left, Right and most of the function keys; not just
single ASCII codes.
That's probably because your terminal window is
On 08/12/2016 07:24, Gregory Ewing wrote:
BartC wrote:
(I'm in the middle of porting my console editor to Linux. But one
problem is that on one Linux, half the key combinations (eg.
Shift+Ctrl+B) are not recognised.
If you're reading characters from a tty device in raw
mode (which I assume i
BartC wrote:
Which means that input of A B* *C will all end up running together so
that you have no idea what is what or which file corresponds to which
expansion.
So if you intend your program to be used on unix, you
need to design it so that it doesn't depend on such
distinctions.
Now the p
On 12/07/2016 11:26 PM, Gregory Ewing wrote:
> BartC wrote:
>> println dirlist(cmdparams[2])# Windows
>> println tail(cmdparams) # Linux
>
> I'm not familiar with your language, so I'll reply
> in Python. If you write it like this:
>
> for arg in sys.argv[1:]:
>
BartC wrote:
println dirlist(cmdparams[2])# Windows
println tail(cmdparams) # Linux
I'm not familiar with your language, so I'll reply
in Python. If you write it like this:
for arg in sys.argv[1:]:
for name in glob(arg):
print(name)
then the user will
BartC wrote:
Only the tiny minority that can be meaningfully invoked on an arbitrary
number of files at the same time.
Um... you mean the "tiny minority" that includes just
about *every* unix utility that operates on files?
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
BartC wrote:
And globbing doesn't take care of all of it: a Linux program still has
to iterate over a loop of filenames. The same as on Windows, except the
latter will need to call a function to deliver the next filename.
Actually, most of them will require *two* loops, one to
iterate over a s
Paul Moore wrote:
On Tuesday, 6 December 2016 21:44:18 UTC, Gregory Ewing wrote:
What you need to understand is that, to a Unix user, * and ? are *just as
well known* as |, < and >.
And to Windows users. Just because BartC is proposing a silly distinction
between what "Unix users" and "Windo
Steve D'Aprano wrote:
I don't know any Unix programs that provide
file spec processing.
'find' does, but only for its -name argument, and only because
it does something different with it from what the shell would
do. And you do need to quote it if it contains glob characters.
--
Greg
--
https:
On Thursday 08 December 2016 12:15, BartC wrote:
> On 08/12/2016 00:09, Steve D'Aprano wrote:
>> On Thu, 8 Dec 2016 02:48 am, BartC wrote:
>
>>> You make it sound like a big deal. Here's a program (in my language not
>>> Python) which prints the list of files matching a file-spec:
>>>
>>> println
On Thursday 08 December 2016 11:34, BartC wrote:
> On 07/12/2016 23:35, Steve D'Aprano wrote:
>> On Thu, 8 Dec 2016 02:19 am, BartC wrote:
>>
>>> On 07/12/2016 14:34, Steve D'Aprano wrote:
>> [...]
I don't know why you are so hung up over the number of characters here,
or this bogeyman o
On 08/12/2016 00:09, Steve D'Aprano wrote:
On Thu, 8 Dec 2016 02:48 am, BartC wrote:
You make it sound like a big deal. Here's a program (in my language not
Python) which prints the list of files matching a file-spec:
println dirlist(cmdparams[2])
Does dirlist provide an escaping mechanism
On Thu, Dec 8, 2016 at 10:35 AM, Steve D'Aprano
wrote:
> In the Unix world, I'm at the mercy of *one* program, the shell. In your
> ideal world, I'm at the mercy of EVERY program that implements globbing:
> each and every one has to independently offer a way to disable their own
> internal globbin
On 07/12/2016 23:35, Steve D'Aprano wrote:
On Thu, 8 Dec 2016 02:19 am, BartC wrote:
On 07/12/2016 14:34, Steve D'Aprano wrote:
[...]
I don't know why you are so hung up over the number of characters here,
or this bogeyman of "one million files" in a directory.
Because /you/ brought it up a
On Thu, 8 Dec 2016 07:01 am, Skip Montanaro wrote:
> Some things are better just left alone. File globbing is probably one
> of those things. There's no right answer, and the people in the two
> camps will never come to a compromise.
Be fair Skip, we've already repeatedly acknowledged that the Un
On Thu, 8 Dec 2016 02:48 am, BartC wrote:
> On 07/12/2016 13:58, Dennis Lee Bieber wrote:
>> On Wed, 7 Dec 2016 11:54:35 +, BartC declaimed the
>> following:
>>
>>> With automatic expansion, then EVERY program can become dangerous. Can
>>> no one else see this?
>>>
>>
>> With your scheme, EVE
On Thu, 8 Dec 2016 02:19 am, BartC wrote:
> On 07/12/2016 14:34, Steve D'Aprano wrote:
[...]
>> I don't know why you are so hung up over the number of characters here,
>> or this bogeyman of "one million files" in a directory.
>
> Because /you/ brought it up as a reason why 'globbing' would help
BartC writes:
> On 07/12/2016 15:25, Ben Bacarisse wrote:
>> BartC writes:
>>
>>> [...] But remember:
>>>
>>> cp *.c
>>>
>>> There might be some irate users out there if it can't detect a simple
>>> user error like that.
>>
>> There might be. They are ill-served by current Unix shells. But,
On Thu, Dec 8, 2016 at 7:17 AM, eryk sun wrote:
> On Wed, Dec 7, 2016 at 12:39 PM, Chris Angelico wrote:
>> Note that two of the Beauty Stone tracks include quotes as well as
>> question marks. How do you identify those? Let's say you want to play
>> one of these in VLC, and then maybe you decide
Op 07-12-16 om 19:02 schreef BartC:
> On 07/12/2016 16:53, Michael Torrie wrote:
>> On 12/07/2016 08:48 AM, BartC wrote:
>>> I would prefer that the program "t" can be invoked exactly the same way
>>> under both systems. I don't want different instructions for Linux, or
>>> for the user (of my lang
On Wednesday December 7 2016 14:57, in comp.lang.python, "BartC"
wrote:
> On 07/12/2016 18:02, BartC wrote:
>
>> If I want to run a Windows program on Linux, and that program needs to
>> see *.* unexpanded, then it can't undo that expansion. The cat is
>> already out of the bag.
>
> I mean, the
On Wed, Dec 7, 2016 at 12:39 PM, Chris Angelico wrote:
> Note that two of the Beauty Stone tracks include quotes as well as
> question marks. How do you identify those? Let's say you want to play
> one of these in VLC, and then maybe you decide that the track in
> Pirates of Penzance/MusicOnly is
On 07/12/2016 18:02, BartC wrote:
If I want to run a Windows program on Linux, and that program needs to
see *.* unexpanded, then it can't undo that expansion. The cat is
already out of the bag.
I mean, the genie is out of the bottle, whatever. You know what I mean,
the operation is not rever
On Wed, Dec 7, 2016 at 12:17 PM, Anton Mamaenko wrote:
> Wow... this thread gets to finally become a holy war.
It's not like this particular holy war is new, either. I'm sure it was
beaten to death in the days before Windows was a thing. As I indicated
in an earlier note, VMS and Unix did command
On 07/12/2016 15:25, Ben Bacarisse wrote:
BartC writes:
[...] But remember:
cp *.c
There might be some irate users out there if it can't detect a simple
user error like that.
There might be. They are ill-served by current Unix shells. But,
oddly, the flow has gone the other way. Peopl
Wow... this thread gets to finally become a holy war. One method is dealing
with this is take the environment as granted (Windows/Unix/Linux/MacOS/Dos
sucks while my
Windows/Unix/Linux/MacOS/Dos is the best) and figure if the hassle of porting
(time, tech, AND moral) worth it. He just "do not
On 07/12/2016 16:53, Michael Torrie wrote:
On 12/07/2016 08:48 AM, BartC wrote:
I would prefer that the program "t" can be invoked exactly the same way
under both systems. I don't want different instructions for Linux, or
for the user (of my language) to have to write two lots of code, as that
i
On 12/07/2016 07:57 AM, BartC wrote:
> I don't follow you. "?" is problematical on both systems. I think
> Windows disallows it completely: I get 'Protocol error' if I copy such a
> file from Linux to Windows. Presumably there is an escaping system, but
> I don't know what it is.
As Chris says,
On 12/07/2016 08:48 AM, BartC wrote:
> I would prefer that the program "t" can be invoked exactly the same way
> under both systems. I don't want different instructions for Linux, or
> for the user (of my language) to have to write two lots of code, as that
> is my job...
Ahh now we come to the
On 12/07/2016 07:58 AM, Marko Rauhamaa wrote:
> Steve D'Aprano :
>
>> I don't know any Unix programs that provide file spec processing.
>> (That's not to say that there are absolutely none, only that I don't
>> know of any.)
>
> I can think of "find", "git" and "scp".
>
> Git supports the recurs
On Thu, Dec 8, 2016 at 2:19 AM, BartC wrote:
> OK, but you go first: how does a Linux program tell the difference between:
>
> A B C
>
> which signifies three files, and:
>
> A B C
>
> which means two files, and an option C? And without using escapes!
The option would be called "-C", which me
On Thu, Dec 8, 2016 at 1:57 AM, BartC wrote:
> On 07/12/2016 12:39, Chris Angelico wrote:
>>
>> On Wed, Dec 7, 2016 at 10:54 PM, BartC wrote:
>>>
>>> But if a program existed that took N filename parameters with the purpose
>>> of
>>> deleting each of them, then it can't tell if they were typed i
On 07/12/2016 13:58, Dennis Lee Bieber wrote:
On Wed, 7 Dec 2016 11:54:35 +, BartC declaimed the
following:
With automatic expansion, then EVERY program can become dangerous. Can
no one else see this?
With your scheme, EVERY PROGRAM HAS TO IMPLEMENT ITS OWN GLOBBING.
Only the
BartC writes:
> [...] But remember:
>
> cp *.c
>
> There might be some irate users out there if it can't detect a simple
> user error like that.
There might be. They are ill-served by current Unix shells. But,
oddly, the flow has gone the other way. People have wanted Unix shells
and utilit
On 07/12/2016 14:34, Steve D'Aprano wrote:
On Wed, 7 Dec 2016 11:23 pm, BartC wrote:
On 07/12/2016 05:15, Steven D'Aprano wrote:
On Wednesday 07 December 2016 12:55, BartC wrote:
But even Linux's 128KB will fill if someone wanted a command line that
listed 20,000 files individually. But it w
On Wednesday, 7 December 2016 11:55:01 UTC, BartC wrote:
> With automatic expansion, then EVERY program can become dangerous. Can
> no one else see this?
Please start an elevated command prompt on your PC, and type the command
rmdir /s /q C:\WINDOWS
There are no special characters here, so
On Tuesday, 6 December 2016 21:44:18 UTC, Gregory Ewing wrote:
> BartC wrote:
> > But those would be silly.
> >
> > Some special syntax is known about: | < and > for example. % less so
>
> What you need to understand is that, to a Unix user,
> * and ? are *just as well known* as |, < and >.
And
Steve D'Aprano :
> I don't know any Unix programs that provide file spec processing.
> (That's not to say that there are absolutely none, only that I don't
> know of any.)
I can think of "find", "git" and "scp".
Git supports the recursive "**" wildcard, as well.
Marko
--
https://mail.python.o
On 07/12/2016 12:39, Chris Angelico wrote:
On Wed, Dec 7, 2016 at 10:54 PM, BartC wrote:
But if a program existed that took N filename parameters with the purpose of
deleting each of them, then it can't tell if they were typed in individually
(so indicating a stronger intent), or whether a fing
On Tuesday, 6 December 2016 16:34:10 UTC, Michael Torrie wrote:
> On 12/06/2016 06:52 AM, BartC wrote:
> > Then you don't get utterly ridiculous and dangerous behaviour such as
> > the cp example Paul Moore came up with (that trumps most of mine actually):
>
> It's potentially dangerous agreed.
On Wed, 7 Dec 2016 11:23 pm, BartC wrote:
> On 07/12/2016 05:15, Steven D'Aprano wrote:
>> On Wednesday 07 December 2016 12:55, BartC wrote:
>>
>>> But even Linux's 128KB will fill if someone wanted a command line that
>>> listed 20,000 files individually. But it would be spectacularly bad use
>>>
On Wed, Dec 7, 2016 at 9:43 AM, Chris Angelico wrote:
> Exactly. Back in the 1990s, we had the beginnings of Windows NT, which
> was designed for servers. It had (if I recall correctly) no concept of
> file/directory permissions, little or no notion of process privilege,
> and definitely no way to
On Thu, 8 Dec 2016 12:07 am, eryk sun wrote:
>> latest step is Microsoft's partnership with Canonical (the company behind
>> Ubuntu Linux) to bring bash to Windows.
>
> The partnership with Canonical is to provide an entire Linux
> distribution, sans the kernel. The Windows Subsystem for Linux (W
Chris Angelico :
> $ find Music/ -name *\\?*
I do recommend quoting your wildcard characters.
Yet further nasty security pitfalls in bash programming:
5. Wildcards that don't match any file are left unexpanded.
6. Commands behave unexpectedly when given null lists:
$ ls a b c
a
On Wed, Dec 7, 2016 at 8:30 AM, Steven D'Aprano
wrote:
>
> There are Windows programs which understand globs, like dir. Do you honestly
> expect us to believe that it is okay to use "dir a*" on Windows because dir
> itself expands the glob, but not okay to use "dir a*" on Linux because the
> shell
On Wed, Dec 7, 2016 at 10:54 PM, BartC wrote:
> But if a program existed that took N filename parameters with the purpose of
> deleting each of them, then it can't tell if they were typed in individually
> (so indicating a stronger intent), or whether a finger slipped on a single
> filename and a
On 07/12/2016 05:15, Steven D'Aprano wrote:
On Wednesday 07 December 2016 12:55, BartC wrote:
But even Linux's 128KB will fill if someone wanted a command line that
listed 20,000 files individually. But it would be spectacularly bad use
of a command line interface which was designed for humans.
On 07/12/2016 08:30, Steven D'Aprano wrote:
On Wednesday 07 December 2016 03:41, BartC wrote:
On 06/12/2016 15:44, Michael Torrie wrote:
On 12/06/2016 04:43 AM, BartC wrote:
Yes shell expansion has it's gotchas. But those can all be learned,
Yes, learn to avoid wildcards in command param
On Wed, Dec 7, 2016 at 7:30 PM, Steven D'Aprano
wrote:
> If you accidentally say "del *" on Windows, say, when you meant "z*" for
> example, and Windows deletes all the files in the current directory, do you
> say
> to yourself...?
>
>"Thank the deities that * was expanded by the del command
Steven D'Aprano wrote:
> Tell me Bart, what's the difference between these?
>
> # Linux
> rm *
>
> and
>
> # Windows
> del *
Is there an equivalent to
# touch -- -r
on Windows? Like in
$ tree
.
|-- -r
|-- a
| `-- b
| `-- c
| `-- bar.txt
`-- foo.txt
3 directories, 3 files
On Wednesday 07 December 2016 03:41, BartC wrote:
> On 06/12/2016 15:44, Michael Torrie wrote:
>> On 12/06/2016 04:43 AM, BartC wrote:
>
>> Yes shell expansion has it's gotchas. But those can all be learned,
>
> Yes, learn to avoid wildcards in command parameters at all costs. But we
> both kno
On Wednesday 07 December 2016 10:37, BartC wrote:
> On 06/12/2016 21:44, Gregory Ewing wrote:
>> BartC wrote:
>
>>> And the justification? Well, %ENVIRONMENTVARIABLE% gets converted in
>>> Windows, so why not?!
>>
>> No, the justification is that the Unix convention allows
>> the shell to provide
On Wednesday 07 December 2016 12:55, BartC wrote:
> But even Linux's 128KB will fill if someone wanted a command line that
> listed 20,000 files individually. But it would be spectacularly bad use
> of a command line interface which was designed for humans.
That's EXACTLY the point of having the
On Tue, Dec 6, 2016 at 10:35 PM, Nathan Ernst wrote:
> One other consideration in regards to globbing in the argument list:
> there's a static limit to the byte length of argv. On windows, it's 8191
> bytes (I'm assuming a null-terminator brings that to 8192, which is a weird
> 2**13).
I know str
On Wed, Dec 7, 2016 at 1:30 AM, Dennis Lee Bieber wrote:
> (Bah... win10 seems to share parts of the PowerShell console config with
> the old command prompt -- making it nearly impossible [at least in the
> three days I've been on Win10 after the Win7 drive failed] to configure
> PowerShell to loo
On 12/06/2016 03:21 AM, BartC wrote:
On 06/12/2016 07:37, Larry Hudson wrote:
Now you're suggesting the _shell_ is going to read and process a CVS
file???
What follows a shell command is a set of values a,b,c,d,e. What is encountered
in a CSV is a set
of values a,b,c,d,e. You really can't se
1 - 100 of 204 matches
Mail list logo
