ssue an error message
at parse time? That is, assuming a shell decides to provide an error
message for
LC_ALL=C
: $'\u1234'
as zsh does, does this allow and/or require that same error message to
be produced for
LC_ALL=C
: || : $'\u1234'
Cheers,
Harald van Dijk
On 30/09/2018 00:18, Robert Elz wrote:
Date:Fri, 28 Sep 2018 14:44:55 +0200
From:Harald van Dijk
Message-ID:
| 1. Are the rules for determining the end of a dollar-quoted string
| intended to be fully specified, especially when taking into account
ave come up with something resembling
alias forever='while :; do'
Is the intent really to invalidate such uses? If so, is the intent to
require shells to issue errors for this, or will shells somehow be
allowed to continue implementing it the way it is currently required?
Cheers,
Harald van Dijk
ly achieve the desired effect.
Cheers,
Harald van Dijk
On 28/12/2018 11:08, Joerg Schilling wrote:
Harald van Dijk wrote:
Hi,
Reading <http://austingroupbugs.net/view.php?id=1055#c3292>, I'm very
surprised to discover that how aliases work is being completely
rewritten in a way incompatible with existing shells and existing shell
I can find which is able to handle this.
Cheers,
Harald van Dijk
On 31/12/2018 10:18, Stephane Chazelas wrote:
2018-12-31 06:51:13 +, Harald van Dijk:
[...]
Changing the value of LC_CTYPE after the shell has started
shall not affect the lexical processing of shell commands in
the current shell execution environment or its subshells.
[...]
Good find.
I
On 01/01/2019 20:45, Chet Ramey wrote:
On 12/28/18 2:57 PM, Harald van Dijk wrote:
I gave the example of
alias mycase=case
mycase x in (x) echo ok ;; esac
I do not see how this is supposed to work under the new wording. However,
looking in more detail, I do not see how this is supposed
On 02/01/2019 00:21, Chet Ramey wrote:
On 1/1/19 5:10 PM, Harald van Dijk wrote:
Alias expansion happens "before applying the grammatical rules", so there's
no lookahead. `mycase' is just a word that is subject to alias expansion.
But once you know you have a WORD token
Harald van Dijk
On Tuesday, January 1, 2019 Harald van Dijk wrote:
On 02/01/2019 00:21, Chet Ramey wrote:
> Even if you
> restrict a function name to be a NAME it's still subject to alias
> expansion.
I may be misunderstanding you again here, but if the function name is
neit
On 02/01/2019 02:34, Chet Ramey wrote:
On 1/1/19 8:33 PM, Harald van Dijk wrote:
Ah! Now I think I see how we are interpreting things differently. Am I
understanding correctly that given
echo hello (
you are saying that this will (conceptually) successfully parse a simple
command
On 02/01/2019 13:28, Chet Ramey wrote:
On 1/1/19 10:15 PM, Harald van Dijk wrote:
On 02/01/2019 02:34, Chet Ramey wrote:
On 1/1/19 8:33 PM, Harald van Dijk wrote:
Ah! Now I think I see how we are interpreting things differently. Am I
understanding correctly that given
echo hello (
you
On 02/01/2019 13:32, Robert Elz wrote:
Date:Wed, 2 Jan 2019 03:15:10 +
From:Harald van Dijk
Message-ID:
| But actually... I now wonder if "command name word of a simple command"
| might refer simply to the "cmd_name : WORD" produ
On 02/01/2019 19:13, Chet Ramey wrote:
On 1/2/19 1:44 PM, Harald van Dijk wrote:
That's not how I read it. Alias expansion is performed "after a token has
been delimited, but before applying the grammatical rules." I take that to
mean that the token hasn't been determined
On 02/01/2019 20:37, Robert Elz wrote:
Date:Wed, 2 Jan 2019 19:19:05 +
From:Harald van Dijk
Message-ID: <6bbdaef7-ac0a-e528-a177-7c51c4ba6...@gigawatt.nl>
| What you're describing here is how it's implemented in practice, not how
| i
On 03/01/2019 00:18, Robert Elz wrote:
Date:Wed, 2 Jan 2019 21:52:59 +
From:Harald van Dijk
Message-ID: <9dcb933f-8dd5-62b5-e420-bfbf7fbda...@gigawatt.nl>
| You've left out the part of my message that you replied to that two
| shells *do*
On 04/01/2019 01:13, Robert Elz wrote:
Date:Fri, 4 Jan 2019 00:08:58 +
From:Harald van Dijk
Message-ID: <33439700-ff2c-ae03-ab9c-ee9b43b85...@gigawatt.nl>
| Allowing arbitrary function names is not something other shells
| generally d
d
backslash). If that's during tokenising, then no problem, they would
already be unspecified implicitly. If it's later, then they should be
made explicitly unspecified if they occur in an alias.
Cheers,
Harald van Dijk
On 04/01/2019 11:07, Robert Elz wrote:
Date:Fri, 4 Jan 2019 09:05:32 +
From:Harald van Dijk
Message-ID:
I am re-ordering your paragraph, to address the second point
first, for reasons that will become obvious soon I think...
| but I worry whether going
On 04/01/2019 21:24, Robert Elz wrote:
Date:Fri, 4 Jan 2019 18:44:20 +
From:Harald van Dijk
Message-ID:
| If the intent is to make all the non-trivial cases unspecified, while
| still allowing the previously required behaviour, then aliases ending in
articular graphic representation for any character is prescribed; thus the
common Japanese practice of using the glyph “¥” for the C character “\” is
perfectly legitimate.)
This reasoning seems like it would apply to POSIX equally well.
Cheers,
Harald van Dijk
imple command without any control operator to terminate it.
The standard itself shows the eval command used that way in its
description of that.
It already follows from the grammar that *if* a control operator is
seen, it cannot be taken as part of the simple command.
Cheers,
Harald van Dijk
the comment still makes perfect sense if
you take out the ", unlike the contents of a dot script" bit, I think.
Cheers,
Harald van Dijk
platforms with a POSIX
compliant getopt() on which it does work. Almost all shells, if not all,
rely on extensions and/or make some not-100%-portable assumptions. That
is not a good reason to disregard them.
Cheers,
Harald van Dijk
result you are after
(which I would like to see myself as well, even though I do not feel as
strongly about it as you).
Cheers,
Harald van Dijk
On 15/01/2019 11:03, Joerg Schilling wrote:
Harald van Dijk wrote:
On 14/01/2019 13:32, Joerg Schilling wrote:
posh does not work on platforms with a POSIX compliant getopt(), so there are
other reasons not to take posh into account.
This is misleading. There are platforms with a POSIX
On 15/01/2019 11:15, Joerg Schilling wrote:
Harald van Dijk wrote:
Can there be an alternative rewording that specifies the behaviour in
even more cases, where the resulting text is still both correct and
understandable, and the extra cases are verified to work the same way on
all current
s with a fairly simple implementation that focuses more
on size than on speed.
Cheers,
Harald van Dijk
On 15/01/2019 23:04, Robert Elz wrote:
Date:Tue, 15 Jan 2019 20:38:15 +
From:Harald van Dijk
Message-ID:
| On 15/01/2019 15:13, Joerg Schilling wrote:
| > would make it she slowest shell in the universe.
| parser as well. Testing on its
None print <\> or <>, the two choices that shells pick for a backslash
not followed by anything else in other cases.
Cheers,
Harald van Dijk
there are different situations in other shells that also fail
for other reasons and require major changes to their implementations of
aliases to solve.
Cheers,
Harald van Dijk
On 27/01/2019 21:17, Stephane Chazelas wrote:
2019-01-27 02:29:04 +, Harald van Dijk:
[...]
This proposed resolution does not leave empty aliases (aliases not resulting
in any token) unspecified. I mentioned them before, because they are
mishandled by at least one shell:
$ dash -c
echo DEBUG
works fine in dash AFAICT.
The non-DEBUG case is alias ifdebug=# to comment out the command.
$ dash < alias ifdebug=#
> ifdebug echo DEBUG
> EOF
dash: 3: Syntax error: end of file unexpected
Cheers,
Harald van Dijk
On 28/01/2019 12:27, Geoff Clare wrote:
Harald van Dijk wrote, on 27 Jan 2019:
On 18/01/2019 11:48, Austin Group Bug Tracker wrote:
--
(0004214) geoffclare (manager) - 2019-01-18 11:48
http://austingroupbugs.net/view.php
ash-derived shells... :) That's how I could be sure enough to say it is
easy to fix.
Cheers,
Harald van Dijk
t be tokenised until after alias substitution has taken place, since
alias substitution might affect how they are to be tokenised.
Cheers,
Harald van Dijk
On 01/02/2019 02:55, Robert Elz wrote:
Date:Thu, 31 Jan 2019 22:04:30 +
From:Harald van Dijk
Message-ID: <126fa44f-05bb-abc2-d6c9-40b82b36f...@gigawatt.nl>
|alias foo=bar
|echo foo
|
| alias substitution should not be performed o
N could be parsed as the command name word of a simple
command (see [xref to Section 2.10]), based on this TOKEN and
the tokens (if any) that preceded it, but ignoring whether any
subsequent characters would allow that
Good point, that looks better.
Cheers,
Harald van Dijk
On 01/02/2019 09:56, Robert Elz wrote:
Date:Fri, 1 Feb 2019 08:00:16 +
From:Harald van Dijk
Message-ID: <5cd22a9c-b213-8ffb-da45-f71057eba...@gigawatt.nl>
| I was referring to the second token on the second line, which is foo,
| not foo=bar.
Oh,
t mode, it is
simpler for a script author to write . .. .* than it is to turn off
globskipdot, write .*, and turn globskipdot back on again.
The bug's desired action, allowing the behaviour of aforementioned
shells and considering making it a requirement in the future, looks like
a much better idea to me.
Cheers,
Harald van Dijk
On 01/06/2019 07:25, Stephane Chazelas wrote:
2019-05-31 20:34:05 +0100, Harald van Dijk:
[...]
If there is, is there any plausible use case where the script would turn off
that globskipdot option, rather than simply changing the pattern to cover .
and .. explicitly? If a shell is in that
On 03/06/2019 10:54, Joerg Schilling wrote:
Harald van Dijk wrote:
(Re-sending from the right e-mail address, apologies if it arrives twice.)
On 30/05/2019 20:44, Nick Stoughton wrote:
During today's teleconference we discussed whether the pathname
expansion ".*" should
On 03/06/2019 13:02, Joerg Schilling wrote:
Harald van Dijk wrote:
echo .*/Makefile
which is:
../Makefile ./Makefile
False. Assuming those paths exist and no other paths match, the
currently expected result depends. It can either be what you wrote, or
it can be
On 04/06/2019 15:52, Joerg Schilling wrote:
Harald van Dijk wrote:
Currently, two incompatible behaviours are implemented in shells:
(1) Let the result depend on readdir().
(2) Always omit "." and "..".
With the "globskipdot" option, shells that currently impl
basename is an absolute path
(which as mentioned is questionable), this is doable with just POSIX sh:
${dirname%/}/${basename#"${basename%%[!/]*}"}
Cheers,
Harald van Dijk
his is the required behaviour
and it is a (minor) bug for a few shells to implement it as a no-op.
Cheers,
Harald van Dijk
On 10/06/2019 19:22, Chet Ramey wrote:
On 6/10/19 2:15 PM, Harald van Dijk wrote:
Re: http://austingroupbugs.net/view.php?id=760#c4411 <&0 is a no-op, so it's
unclear whether it counts as
"explicit redirection of standard input".
In almost all shells, <&0 is no
On 10/06/2019 20:25, Chet Ramey wrote:
On 6/10/19 3:15 PM, Harald van Dijk wrote:
On 10/06/2019 19:22, Chet Ramey wrote:
On 6/10/19 2:15 PM, Harald van Dijk wrote:
Re: http://austingroupbugs.net/view.php?id=760#c4411 <&0 is a no-op, so
it's
unclear whether it counts as
"exp
On 11/06/2019 09:39, Geoff Clare wrote:
Harald van Dijk wrote, on 10 Jun 2019:
On 10/06/2019 09:46, Austin Group Bug Tracker wrote:
--
(0004413) geoffclare (manager) - 2019-06-10 08:46
http://austingroupbugs.net/view.php
actually creates a
file named %sn, it will do what the user expects in all shells that I
know of. Your interpretation would require it to break.
Cheers,
Harald van Dijk
On 18/06/2019 10:51, Geoff Clare wrote:
Harald van Dijk wrote, on 17 Jun 2019:
In 2.13.1, "This escaping " refers to the escaping
defined in the previous sentence. The full previous sentence is conditional:
"When pattern matching is used where shell quote removal i
On 19/06/2019 09:43, Geoff Clare wrote:
Harald van Dijk wrote, on 18 Jun 2019:
It seems to me that 2.13.1 should be interpreted as overriding 2.13.3,
as otherwise there would be no point in having that statement there.
It is what clarifies or specifies that `find . -name '\*'`
On 19/06/2019 21:03, Robert Elz wrote:
Date:Wed, 19 Jun 2019 18:30:36 +0100
From:Harald van Dijk
Message-ID:
| If your conclusion is that the intent of the standard is to specify
| something that no shell does
That may have been true at the time the text
On 20/06/2019 09:42, Stephane Chazelas wrote:
2019-06-20 07:57:01 +0100, Harald van Dijk:
[...]
To be clear, I was specifically referring to Geoff Clare's interpretation
that
set -- 'back\slash'
set -- $*
should set $1 to 'backslash', not 'back\slash'
pattern string shall be left unchanged") did have: under
that interpretation, no scan of the current directory would be needed,
as results would be identical regardless of the contents. That is also
an advantage many shells' behaviour of treating unquoted backslash as a
literal character have. But if backslash does also function as an escape
character during pattern matching, it needs to trigger globbing as well.
Cheers,
Harald van Dijk
On 22/06/2019 07:51, Stephane Chazelas wrote:
2019-06-21 23:58:32 +0100, Harald van Dijk:
[...]
In theory, pathname expansion is supposed to be done for every word, no
matter which characters it contains. Even in something as simple as
echo hello
both words undergo pathname expansion. The
On 22/06/2019 01:46, Robert Elz wrote:
Date:Fri, 21 Jun 2019 23:58:32 +0100
From:Harald van Dijk
Message-ID: <49108c83-bd68-a329-25c5-118b0f911...@gigawatt.nl>
| Obviously, this means that pathname expansion produces "echo",
| regardless
On 22/06/2019 13:40, Stephane Chazelas wrote:
2019-06-22 09:07:40 +0100, Harald van Dijk:
[...]
In theory, pathname expansion is supposed to be done for every word, no
matter which characters it contains. Even in something as simple as
[...]
That's your way to look at it.
That'
ng on
ordinary, shell special, and special pattern characters shall apply to
escaping in this context." It explicitly includes ordinary characters there.
Cheers,
Harald van Dijk
rs:
rm -f a b
touch a
echo ~(N)a ~(N)b
This is supposed to produce 'a'.
This particular example is already not required to behave in any
particular way for other reasons, but I do not know whether changes to
this example might produce something where an overly strict requireme
On 24/06/2019 11:04, Joerg Schilling wrote:
Austin Group Bug Tracker wrote:
Where you refer to "*every* shell (except bash5 ...)", that's inaccurate
because:
1. Robert Elz and Harald van Dijk have shells that behave like bash5.
I would be happy to check these shells, but unf
On 24/06/2019 15:16, Chet Ramey wrote:
On 6/22/19 8:57 AM, Harald van Dijk wrote:
But in bash5's
files='/a/\b/??/x/*'
ls -d $files
That \ becomes a globbing operator, so we get the same list of
files as in a literal /a/[b]/??/x/*, not a literal /a/\b/??/x/*
That doesn
r 'emulate
sh' is a supported command and execute it if so. That is enough to get
zsh to enter POSIX mode and accept 'set -f' with the standard meaning.
Cheers,
Harald van Dijk
n to this
extension when coming up with new wording for POSIX.
Cheers,
Harald van Dijk
On 25/06/2019 08:30, Stephane Chazelas wrote:
2019-06-24 21:56:48 +0100, Harald van Dijk:
On 24/06/2019 21:15, Stephane Chazelas wrote:
But that means that those ksh extended glob operators are not
enabled in:
pattern='@(x)'; cmd $pattern
or
case string in $pattern) ...
(for the la
eak scripts, file names that are not actually used in the wild.
Cheers,
Harald van Dijk
On 27/06/2019 07:15, Stephane Chazelas wrote:
2019-06-26 23:56:06 +0100, Harald van Dijk:
[...]
You are proposing a fundamental change to the design of pattern matching,
not a clarification as you previously called it, and you are now discussing
how to allow the behaviour of one specific shell
portably. You responded then:
POSIX intends to create portability at source code level.
Code that is not portable does not follow the POSIX way.
That's not a requirement for POSIX implementations, so it's not relevant.
Cheers,
Harald van Dijk
appears to have many useful extensions, and we should move in that direction. See http://www2.research.att.com/sw/download/man/man1/ksh.html [^] for man page details. New wording invited.
Cheers,
Harald van Dijk
On 28/06/2019 16:05, Joerg Schilling wrote:
Harald van Dijk wrote:
That aside, I asked you last time you made this claim about POSIX to
back it up. There is no requirement for standard utilities to be
implemented portably. You responded then:
POSIX intends to create portability at source
On 28/06/2019 09:38, Geoff Clare wrote:
Harald van Dijk wrote, on 27 Jun 2019:
On 27/06/2019 10:04, Geoff Clare wrote:
Stephane Chazelas wrote, on 26 Jun 2019:
Or again, forget all about it and treat the ksh93 behaviour as
non-compliant as is already the case.
I'm starting to think
On 01/07/2019 10:36, Geoff Clare wrote:
Harald van Dijk wrote, on 30 Jun 2019:
On 28/06/2019 09:38, Geoff Clare wrote:
Harald van Dijk wrote, on 27 Jun 2019:
On 27/06/2019 10:04, Geoff Clare wrote:
In particular, XRAT's explanation of it is "Conforming applications
are require
On 02/07/2019 10:20, Geoff Clare wrote:
Harald van Dijk wrote, on 01 Jul 2019:
On 01/07/2019 10:36, Geoff Clare wrote:
Harald van Dijk wrote, on 30 Jun 2019:
POSIX does not even limit the concept of "syntax errors" to errors in the
syntax, see e.g. the "shift" command
On 03/07/2019 09:24, Geoff Clare wrote:
Harald van Dijk wrote, on 02 Jul 2019:
That's not because the word "unquoted" is used, which only applies to shell
quoting, that's because 2.13.1 contains "All of the requirements and effects
of quoting on ordinary, shell spe
the new wording, it is not clear to me what the intent is.
Cheers,
Harald van Dijk
On 03/07/2019 15:27, Geoff Clare wrote:
Harald van Dijk wrote, on 03 Jul 2019:
On 03/07/2019 11:08, Geoff Clare wrote:
Stephane Chazelas wrote, on 03 Jul 2019:
2019-07-03 09:24:10 +0100, Geoff Clare:
[...]
[...] If any character (ordinary, shell
special
On 04/07/2019 09:09, Geoff Clare wrote:
Harald van Dijk wrote, on 03 Jul 2019:
No, it's a context where shell-quoting backslash *doesn't* work. Therefore
the backslash should act as an escape character just like in find, pax,
fnmatch() and glob().
It's not about shell quotin
he
current pathname component of the pattern includes a metacharacter. That
is, an indirect /de\v/nul[l] does not find /dev/null, but an indirect
/d[e]\v/null does.
In zsh, backslash is given this special treatment only if the next
character is special, so an indirect [a]\? matches a?, but an indirect
[a]\b does not match ab.
Cheers,
Harald van Dijk
On 24/09/2019 12:24, Geoff Clare wrote:
Harald van Dijk wrote, on 24 Sep 2019:
2. Existing practice in most shells that do treat backslash as special in
"indirect" patterns in pathname expansions is only to match patterns
against existing pathnames if the pattern includes a &
On 24/09/2019 15:32, Geoff Clare wrote:
Harald van Dijk wrote, on 24 Sep 2019:
There is a reason I wrote "in its current version". I do not think it is
reasonable to describe bash 4 behaviour that had already been changed when
this was being discussed as "existing practice"
On 25/09/2019 10:22, Geoff Clare wrote:
Harald van Dijk wrote, on 24 Sep 2019:
Regardless, a single shell is not enough to say "most shells", not even if
it is multiple versions of that single shell.
I consider bash 4 on Linux and bash 3 on macOS to be different shells.
(T
lob option is enabled. I can think of some possible ways
to handle that, but unless POSIX adds these options, determining how
they should interact with indirect backslashes should probably not be
done on this list.
Cheers,
Harald van Dijk
the pattern [[="x="]] should change
to "one of [=x=, followed by ]", just like how the pattern [["=x="]] is
treated already. Does that sound right?
Cheers,
Harald van Dijk
On 25/09/2019 22:49, Stephane Chazelas wrote:
2019-09-25 22:29:36 +0100, Harald van Dijk:
[...]
1a. Invalid character classes:
case x in [x[:bogus:]]) echo x ;; esac # bash,bosh,mksh,nbsh,osh,zsh
case x in [![:bogus:]]) echo x ;; esac # above except osh
[...]
See also
https://www.mail
YPE, but
by stating that the minimum set of error return values includes
REG_ECTYPE, the standard requires regcomp() to return REG_ECTYPE for at
least some patterns.
Cheers,
Harald van Dijk
On 26/09/2019 01:47, Robert Elz wrote:
Date:Wed, 25 Sep 2019 22:29:36 +0100
From:Harald van Dijk
Message-ID:
| These all seem reasonable choices. regcomp() would reject the whole
| pattern as an error, and character classes are supposed to behave as
On 26/09/2019 02:36, Harald van Dijk wrote:
POSIX mentions the possibility of locale-specific character classes and
they are required to be recognised in regular expressions and therefore
in shell glob patterns:
In addition, character class expressions of the form:
[:name:]
are recognized
On 26/09/2019 14:27, Joerg Schilling wrote:
Harald van Dijk wrote:
Not the same way, but it could still be trivially fixed: instead of
as_echo='printf %s\n'
configure scripts could do
as_echo() { printf '%s\n' "$@"; }
as_echo=as_echo
Well,
characters in '[:alpha', followed by ':]]', is something I only see in
osh and in your shell.
Cheers,
Harald van Dijk
kslash as it loses its special
meaning in bracket expressions, but shell quoting allows arbitrary
characters to appear. What should the shell do when fed [[=".=]"=]]? How
is this implementable?
Cheers,
Harald van Dijk
y required to match
single characters in the text being matched, that is doable.
Cheers,
Harald van Dijk
ent on applications, is it not? When
that requirement is violated, the regular expression or shell pattern is
undefined, and interpreting alpha] as an invalid character class name is
a reasonable result.
Cheers,
Harald van Dijk
On 27/09/2019 02:26, Robert Elz wrote:
Date:Thu, 26 Sep 2019 22:58:10 +0100
From:Harald van Dijk
Message-ID:
| 9.3.5 rule 1:
| "shall be followed by" is a requirement on applications, is it not?
It is.
| When that requirement is vio
that
this is not a bracket expression, despite the word containing what would
be a bracket expression when used in other contexts, therefore this
would be required to expand to "[/\.]" regardless of the contents of the
file system. Is that understanding correct?
Cheers,
Harald van Dijk
On 30/09/2019 10:51, Geoff Clare wrote:
Harald van Dijk wrote, on 28 Sep 2019:
On 23/09/2019 16:39, Austin Group Bug Tracker wrote:
--
(0004564) geoffclare (manager) - 2019-09-23 15:39
http://austingroupbugs.net/view.php
On 30/09/2019 12:00, Geoff Clare wrote:
Harald van Dijk wrote, on 30 Sep 2019:
(As an aside, why is this exception limited to patterns used for filename
expansion? Existing practice is that it applies to all patterns:
case [a in [*) echo match ;; *) echo no match ;; esac
This prints &qu
ur is that indirect [a]\/b and a\/[b] both find a file named 'b'
in a directory named 'a'.
Is my understanding correct? If so, should these patterns become
unspecified as well, to allow current and older shell behaviour?
Cheers,
Harald van Dijk
ed backslashes before slash in glob() is probably a
step too far.
Cheers,
Harald van Dijk
On 24/10/2019 00:42, Robert Elz wrote:
Date:Wed, 23 Oct 2019 20:58:08 +0100
From:Harald van Dijk
Message-ID:
| That is, if a user runs
|echo "/dev/"*
| dash will call glob() with a pattern string of '\/dev\/*'.
Bizarre.
On 24/10/2019 08:16, Robert Elz wrote:
Date:Thu, 24 Oct 2019 06:46:52 +0100
From:Harald van Dijk
Message-ID: <5d23eeba-1ac5-6574-d348-2a8b43f97...@gigawatt.nl>
| This is currently well-defined. We are talking about changing the
| standard to m
1 - 100 of 206 matches
Mail list logo
